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

[Kevin Wolf]

Am 30.11.2010 15:12, schrieb Anthony Liguori:
> 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.

Yeah, it's not a huge surprise, even though nobody could tell if it
wouldn't be a week or two earlier or later. But it's the same pattern as
we've had before with 0.13. Fork on very short notice and a RC phase
that was planned to be short, and that results in a hurry to get
everything in, in whatever state it may be.

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

I don't quite agree with that (we have released 0.13 in October, so I'm
not sure why it's so important to get the next release very soon), but I
understand that I should have mentioned this before and not only now.
Anything that will help avoiding option 2 as much as possible is fine
with me.

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

The point is that we should pay attention that the quality of git master
doesn't get worse shortly before a release because everything pushes his
half-baked patches. Otherwise, if a release is only "a bit better" than
git, it might not be better than a git snapshot when there's no release.

For a longer RC phase to work, it's obviously even more important that
we take the freeze serious and treat it as a stable branch (in the
future including the Ack process).

I think that's one of the few things that has worked pretty well for
0.13. It might have been because everyone thought you'd release
"tomorrow", so they didn't dare asking you to include more patches
except for really important fixes - but I think this should be the
regular process for RCs. After all they are "release candidates", not
"some beta".

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

Sounds good. I should be able to get the block patches in until then
even with a proper review and some testing.

Kevin