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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Oct 08, 2015 at 02:39:40PM +0200, Juergen Gross wrote:
> 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.
> 

+1.

I think it's whole community's burden to run a community driven project.
Nobody would think that you push work to others because you think their
time is less valuable than yours.

> 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."
> 

+1.

That's why various people mean  team of stable release maintainers,
automation tools and other technical / procedural solutions.

But until we figure out what the real pain points are item by item,
there is no answers to how to solve them.

In any case, I'm all for spreading the burden.

Wei.

> 
> Juergen

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