On Wed, 30 Sep 2009 17:03:23 +0200 Fred Leeflang <fredl@xxxxxxxxxxx> wrote: > 2009/9/30 Anthony Liguori <aliguori@xxxxxxxxxx> > > > Luiz Capitulino wrote: > > > >> On Tue, 29 Sep 2009 18:54:53 -0500 > >> Anthony Liguori <aliguori@xxxxxxxxxx> 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. Not exactly, freezing is done to stop/slowdown writing new code and focus on bug fixing for a period of time. This is not only needed for a release, but projects should always try to find the best balance between 'number of bugs' and 'feature addition rate'. > 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. Having a functional and relatively stable release is not only important, but it's the ultimate goal IMO. Obviously we should take care not to take extremes. No QEMU release will be 100% bug free, that's why we have stables. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
