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