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

[Brian Jackson]

On Monday, November 29, 2010 11:42:49 am 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


Have you considered a frozen master style release like other projects use? 
(Linux kernel, etc.)

Every project I follow that does this "branch stable keep master moving" 
release thing has terrible releases every time. Patches don't make it back 
into stable,etc... Basically a lot of the same stuff we saw for 0.13.



> 
> 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.
> 
> Thoughts?
> 
> Regards,
> 
> Anthony Liguori