Re: RFC: LTS and stable release scheme

[Juergen Gross <jgross@suse.com>]

On 10/08/2015 02:22 PM, Jan Beulich wrote:
>>>> On 08.10.15 at 13:49, <JGross@suse.com> wrote:
>> On 10/08/2015 01:34 PM, Jan Beulich wrote:
>>>>>> On 08.10.15 at 12:59, <Ian.Jackson@eu.citrix.com> 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