qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan
Date: Tue, 30 Nov 2010 11:15:21 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10

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

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


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. After all, 0.13 was
a bit of a mess because nobody knew when it would be released, but in
the end I don't think the additional time to stabilize in stable-0.13
hasn't hurt.

I admit that three months was really a bit long, but I think if we
planned for more than 10 days from the fork to the release (maybe a
month?), we would have much less trouble with predictability.

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

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]