From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: RFC: LTS and stable release scheme Date: Thu, 8 Oct 2015 14:39:40 +0200 Message-ID: <5616640C.5000909@suse.com> References: <20151006110758.GV29124@zion.uk.xensource.com> <5613EAF602000078000A8959@prv-mh.provo.novell.com> <20151006140909.GF29124@zion.uk.xensource.com> <5613FC4702000078000A8A69@prv-mh.provo.novell.com> <56163FFF02000078000A9303@prv-mh.provo.novell.com> <22038.19617.155508.482730@mariner.uk.xensource.com> <561670CD02000078000A94AA@suse.com> <5616582F.5000303@suse.com> <56167C0802000078000A953E@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZkAU4-0000Ut-D6 for xen-devel@lists.xenproject.org; Thu, 08 Oct 2015 12:39:44 +0000 In-Reply-To: <56167C0802000078000A953E@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Lars Kurth , Wei Liu , Ian Campbell , George Dunlap , Andrew Cooper , Doug Goldstein , xen-devel , Steven Haigh , Ian Jackson List-Id: xen-devel@lists.xenproject.org On 10/08/2015 02:22 PM, Jan Beulich wrote: >>>> On 08.10.15 at 13:49, wrote: >> On 10/08/2015 01:34 PM, Jan Beulich wrote: >>>>>> On 08.10.15 at 12:59, 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