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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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