From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mt0iK-000499-AT for qemu-devel@nongnu.org; Wed, 30 Sep 2009 11:03:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mt0iF-00044o-EV for qemu-devel@nongnu.org; Wed, 30 Sep 2009 11:03:31 -0400 Received: from [199.232.76.173] (port=33234 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mt0iF-00044V-3b for qemu-devel@nongnu.org; Wed, 30 Sep 2009 11:03:27 -0400 Received: from ey-out-1920.google.com ([74.125.78.150]:4766) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mt0iE-0000vd-DH for qemu-devel@nongnu.org; Wed, 30 Sep 2009 11:03:26 -0400 Received: by ey-out-1920.google.com with SMTP id 13so4031094eye.14 for ; Wed, 30 Sep 2009 08:03:23 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4AC36F0C.8020400@us.ibm.com> References: <4AC29E4D.80707@us.ibm.com> <20090930103001.21aa7a8d@doriath> <4AC36F0C.8020400@us.ibm.com> Date: Wed, 30 Sep 2009 17:03:23 +0200 Message-ID: <30defc5b0909300803y4edcfca3p7ca2a7ee079d72a7@mail.gmail.com> Subject: Re: [Qemu-devel] Release plan for 0.12.0 From: Fred Leeflang Content-Type: multipart/alternative; boundary=0016364d1ce30fa80b0474ccd5da List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kvm-devel , "qemu-devel@nongnu.org" , Luiz Capitulino , Blue Swirl , Paul Brook , "Edgar E. Iglesias" , Aurelien Jarno --0016364d1ce30fa80b0474ccd5da Content-Type: text/plain; charset=ISO-8859-1 2009/9/30 Anthony Liguori > Luiz Capitulino wrote: > >> On Tue, 29 Sep 2009 18:54:53 -0500 >> Anthony Liguori wrote: >> >> >> >>> I think aiming for early to mid-December would give us roughly a 3 month >>> cycle and would align well with some of the Linux distribution cycles. I'd >>> like to limit things to a single -rc that lasted only for about a week. >>> This is enough time to fix most of the obvious issues I think. >>> >>> >> >> How do you plan to do it? I mean, are you going to create a separate >> branch >> or make master the -rc? >> >> Creating a separate branch (which is what we do today, iiuc) makes it >> get less attention, freezing master for a certain period is the best >> way to stabilize. >> >> Is this what you had in mind? >> >> > What do people think? > > One reason I branch is because some people care a bit less about releases > so it makes the process non-disruptive to them. If the other maintainers > agreed though, I would certainly like to have the master branch essentially > frozen for the week before the release. > freezing is only neccesary if you need time to gather all the patches, build and test them together etc. If you don't feel you or the developers need to do that to get a reliable release out I think it only halts developers without any clear reason to do so. Calling 'attention' to a release is not a clear reason IMO. -Fred --0016364d1ce30fa80b0474ccd5da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2009/9/30 Anthony Liguori <aliguori@us.ibm.com><= /span>
Luiz Capitulino wrote:
On Tue, 29 Sep 2009 18:54:53 -0500
Anthony Liguori <aliguori@us.ibm.com> wrote:

=A0
I think aiming for early to mid-December would give us roughly a 3 month cy= cle and would align well with some of the Linux distribution cycles. =A0I&#= 39;d like to limit things to a single -rc that lasted only for about a week= . =A0This is enough time to fix most of the obvious issues I think.
=A0 =A0

=A0How do you plan to do it? I mean, are you going to create a separate bra= nch
or make master the -rc?

=A0Creating a separate branch (which is what we do today, iiuc) makes it get less attention, freezing master for a certain period is the best
way to stabilize.

=A0Is this what you had in mind?
=A0
What do people think?

One reason I branch is because some people care a bit less about releases s= o it makes the process non-disruptive to them. =A0If the other maintainers = agreed though, I would certainly like to have the master branch essentially= frozen for the week before the release.
=A0
freezing is only neccesary if you need time to gat= her all the patches, build and test them together etc. If you don't feel you or the developers need to do that to get a reliable release out I think it only halts developers without any clear reason to do so. Calling 'atten= tion' to a release is not a clear reason IMO.

-Fred
--0016364d1ce30fa80b0474ccd5da--