Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan

[Alexander Graf]

On 29.11.2010, at 20:29, Anthony Liguori wrote:

> On 11/29/2010 12:10 PM, Alexander Graf wrote:
>> On 29.11.2010, at 18:42, Anthony Liguori wrote:
>> 
>>   
>>> Hi,
>>> 
>>> 0.13 was a mess of a release (largely due to my lack of time) and I'd like 
>>> to get us back onto a predictable schedule.
>>> 
>>> Here's what I propose:
>>> 
>>> 12/6 - fork off stable-0.14 tree; simultaneously release qemu-0.14.0-rc0
>>> 
>>> For the stable-0.14 tree, I'd like to have Justin be in charge of 
>>> collecting patches.  For stable-0.14 submissions, patches (or pull 
>>> requests) specifically marked as [STABLE 0.14] should be sent to the 
>>> mailing list that are tested against that tree.  Sending a patch to against 
>>> master with a comment saying "this should probably go to stable too" is not 
>>> enough.
>>> 
>>> 12/10 - release qemu-0.14.0-rc1
>>> 
>>> 12/15 - release qemu-0.14.0-rc2; this should be the final release candidate 
>>> with no changes make for GA other than a version bump
>>> 
>>> 12/17 - release qemu-0.14.0
>>> 
>>> Post qemu-0.14.0, Justin will handle the stable tree and subsequent stable 
>>> releases.
>>> 
>>> The rules for stable will continue to be what they are now.  Only bug fixes 
>>> that are patches committed in master are candidates for stable (except in 
>>> rare circumstances where that is not viable).
>>> 
>>> I think we should also try to implement an Ack process for stable.  For 
>>> instance, I think it would make sense for Justin to send out stable patch 
>>> candidates regularly and require 3 community Acked-by's for the patch to go 
>>> into stable.  I'm not sure if this is too much process but by the same 
>>> token, as long as we full the above rule, this should be a trivial step for 
>>> folks to follow.
>>>     
>> 3 is quite a lot.
>>   
> 
> Is 2 just right?

I was thinking of a more sophisticated model. Maybe 1 maintainer + 1 user? Or 1 
person who knows his way around the area + 1 more?

> 
>>> Thoughts?
>>>     
>> Please set up a mailing list we can just CC for stable candidates, so they 
>> don't get lost. Motivation for keeping track of stable stuff differs between 
>> developers and it's essential to make the kick-off easily accessible. It's 
>> worked out very well for Linux, so why not for us?
>>   
> 
> Is the desire to filter mail or have private discussions that are not on 
> qemu-devel?
> 
> If it's the former, a [STABLE] tag in the subject would work just as well.  
> If it's the later, I think it runs contrary to the goal of getting more 
> people involved in stable.

The desire is to have an easy to set tag. [STABLE] to me indicates that the 
patch is specifically made for stable. CC to stable@ tells me that the patch 
should go into stable as soon as it's submitted upstream and if it doesn't 
apply cleanly, the stable maintainer nags the author about a backport.


Alex