Re: [Xen-devel] RFC: LTS and stable release scheme

[Juergen Gross <jgross@xxxxxxxx>]

On 10/08/2015 02:22 PM, Jan Beulich wrote:
> > > > On 08.10.15 at 13:49, <JGross@xxxxxxxx> wrote:
> > On 10/08/2015 01:34 PM, Jan Beulich wrote:
> > > > > > On 08.10.15 at 12:59, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> > > > Jan Beulich writes ("Re: [Xen-devel] RFC: LTS and stable release scheme"):
> > > > > Perhaps there's room for further automation here, yet as with
> > > > > any automation the question is how quickly getting this in place
> > > > > will amortize itself.
> > > > Even with the current situation I think much more automation would be
> > > > good.  (But then I'm someone who really (a) likes automating things
> > > > (b) likes sitting back and watching the automation do its thing and
> > > > even (c) likes debugging the automation when it goes wrong.)
> > > >
> > > > I think that maybe as a starting point, Jan and I could agree that
> > > > instead of build-testing our backports locally, we will throw them at
> > > > osstest and see what sticks.
> > > Well, yes, we could. Otoh the overhead of fixing something that
> > > didn't build but got committed already means more mechanical
> > > work (revert, or create a fixup patch) compared to fixing it before
> > > pushing to the respective staging tree.
> > >
> > > What I would see as possibly useful would be a queue like thing
> > > where backports could be added, and automation would take
> > > care of committing and pushing as much of it as it can validate
> > > to build (more severe problems are pretty rare in stable trees,
> > > and hence relying on the normal osstest there like we do now
> > > would seem reasonable). Yet again this would mean one may
> > > have to turn attention to the respective tree more often (since
> > > right now this is needed just once for each batch of backports,
> > > unless something really odd happens).
> > Couldn't that purely mechanical work be spread to others? I can't
> > believe this would require exceptional skills and I think your
> > time is to precious for stuff like that.
> >
> > In the beginning the workflow could be the same as yours today,
> > there would be just the queue you mentioned and someone either
> > doing the builds and committing or just look after the results
> > of any automatism. It just wouldn't be you.
> I really dislike considering my time more precious than that of
> other people. Hence I'm rather hesitant to push work onto
> others, albeit I've learned that I can't do entirely without (but
> then on the basis of them being more knowledgeable about
> things or it really being their responsibility, not their time being
> less valuable).
Okay, let me rephrase this:

You are already doing quite a lot for the Xen project (committer, x86
maintainer, a huge amount of reviews) resulting in your time being
available to productive topics seems to be of higher priority than
not spreading more or less mechanical work to others. I can
understand you are feeling a little bit uneasy letting others do this
maybe even dumb work (no offence), but I hope there would be someone
volunteering for that task. If not, this discussion is moot, of course.

You can put it this way: you are seeing a problem with a shorter release
cycle due to the suspected higher workload required doing purely
mechanical work. Maybe the desire for a shorter release cycle is so high
that someone steps up and says: "hey, no problem, let me do that purely
mechanical work, so your problem isn't existing any more."


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel