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

[Anthony Liguori <anthony@codemonkey.ws>]

On 11/30/2010 04:15 AM, Kevin Wolf wrote:
> Am 29.11.2010 18:42, schrieb Anthony Liguori:
>    
>> 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.
>>      
> Telling people six days in advance when the fork will be is hardly
> predictable. :-)
>    

Yeah, I've been mentioning the desire to do 0.14 by EOY so hopefully it 
wasn't a huge surprise but it's certainly a valid statement.

> For example, in the block area there are currently a lot of interesting
> patches on the list (AHCI, SCSI, block-queue, QED, Ceph) and there's no
> way to integrate them in time if we don't want to blindly apply patches
> and then see what breaks.
>
> What to do with them? The options I see are:
>
> 1. Move them all to 0.15 (when will it be?)
>    

Every 6 months so it would be June 2011.

> 2. Apply everything now, have a broken rc0 and hope to fix everything
>     in the short time until rc2
> 3. Fork 0.14 shortly before Christmas and move the release to January
>
> The usual approach for dealing with feature freeze deadlines seems to be
> option 2, though I don't really like that one...
>    

Yeah, obviously not the right thing to do.

Even though it sucks, I'd really like to do 0.14 before the year ends.

> For 0.15 I suggest that the fork date should be announced at least a
> month in advance and that we have a longer RC phase.

By having a short -rc cycle, I'm trying to avoid the last minute push to 
include a lot of functionality into a release which usually ends up in 
things getting included before they're ready.

A short -rc cycle means that we get a .0 release that's a bit better 
than a git snapshot but ultimately is really just a point-in-time 
release verses a feature driven release.

We can certainly try a one month -rc cycle for 0.15.  With Justin 
helping, it might be much more useful than in the past.

We could push the final 0.14.0 release to 12/30 and I can make sure to 
be around to handle -rcs.  I suspect that the extra couple weeks over 
the holidays won't matter all that much but it gives everyone a bit more 
time before the tree freezes.  That would put us around 12/17 for 
stable-0.14 fork.

>> 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.
>>      
> I think three Acks might be a bit too much, but requiring one or two
> Acks probably makes sense. Though I think we need to consider that there
> are areas where it would be easy to get five Acks, and other areas where
> it's going to be hard enough to get at least one.
>    

Certainly true.

Regards,

Anthony Liguori

> Kevin
>