From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55262 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1POHIq-0004I6-I9 for qemu-devel@nongnu.org; Thu, 02 Dec 2010 17:07:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1POHIo-0005L8-Vm for qemu-devel@nongnu.org; Thu, 02 Dec 2010 17:07:00 -0500 Received: from theiggy.com ([66.220.1.110]:44402 helo=mail.theiggy.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1POHIo-0005KA-RI for qemu-devel@nongnu.org; Thu, 02 Dec 2010 17:06:58 -0500 From: Brian Jackson Subject: Re: [Qemu-devel] [RFC] QEMU 0.14.0 release plan Date: Thu, 2 Dec 2010 16:06:49 -0600 References: <4CF3E619.5000309@codemonkey.ws> In-Reply-To: <4CF3E619.5000309@codemonkey.ws> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012021606.49555.iggy@theiggy.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: "Justin M. Forbes" 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