On 29.11.2010, at 20:29, Anthony Liguori wrote: > On 11/29/2010 12:10 PM, Alexander Graf wrote: >> On 29.11.2010, at 18:42, 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 >>> >>> 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. >>> >> 3 is quite a lot. >> > > Is 2 just right?
I was thinking of a more sophisticated model. Maybe 1 maintainer + 1 user? Or 1 person who knows his way around the area + 1 more? > >>> Thoughts? >>> >> Please set up a mailing list we can just CC for stable candidates, so they >> don't get lost. Motivation for keeping track of stable stuff differs between >> developers and it's essential to make the kick-off easily accessible. It's >> worked out very well for Linux, so why not for us? >> > > Is the desire to filter mail or have private discussions that are not on > qemu-devel? > > If it's the former, a [STABLE] tag in the subject would work just as well. > If it's the later, I think it runs contrary to the goal of getting more > people involved in stable. The desire is to have an easy to set tag. [STABLE] to me indicates that the patch is specifically made for stable. CC to stable@ tells me that the patch should go into stable as soon as it's submitted upstream and if it doesn't apply cleanly, the stable maintainer nags the author about a backport. Alex
