From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LWlvG-0000v9-MJ for qemu-devel@nongnu.org; Tue, 10 Feb 2009 01:16:42 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LWlvB-0000td-Gd for qemu-devel@nongnu.org; Tue, 10 Feb 2009 01:16:42 -0500 Received: from [199.232.76.173] (port=49127 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LWlvB-0000tP-8K for qemu-devel@nongnu.org; Tue, 10 Feb 2009 01:16:37 -0500 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:59739 helo=grelber.thyrsus.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LWlvA-0007XI-Tu for qemu-devel@nongnu.org; Tue, 10 Feb 2009 01:16:37 -0500 From: Rob Landley Subject: Re: [Qemu-devel] Cutting a new QEMU release Date: Mon, 9 Feb 2009 18:47:37 -0600 References: <4988AD96.6090308@codemonkey.ws> <1234183414.13728.30.camel@blaa> In-Reply-To: <1234183414.13728.30.camel@blaa> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902091847.37612.rob@landley.net> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Mark McLoughlin On Monday 09 February 2009 06:43:34 Mark McLoughlin wrote: > On Tue, 2009-02-03 at 14:48 -0600, Anthony Liguori wrote: > > What do people think? TCG seems to be in a good place. We've got > > virtio, KVM, live migration, tons of new devices, bsd-user, etc. > > > > We could decide to cut one by the end of the month. I'm already doing > > some test work in QEMU so I can follow up with some more detailed notes > > about what is working and what isn't working. That gives us some time > > to decide if there's anything we need to fix before a release. > > Sounds great to me. > > From a Fedora perspective, qemu-0.9.1 is a year old and upstream has > moved on a lot. As a package maintainer, it's hard to justify caring too > much about bugs reported against 0.9.1, since the bug is likely to have > very little relevance to the latest upstream. > > Also, it would be really nice to have a kvm-userspace based off a solid > qemu release ... qemu moving so fast is great, but it means it's hard to > predict the stability of a given kvm-userspace release. I'd like to point out a relevant Google tech talk video: http://video.google.com/videoplay?docid=-5503858974016723264 April 19, 2007 Release Management in Large Free Software Projects - Martin Michlmayr (Debian) ABSTRACT: Time based releases are made according to a specific time interval, instead of making a release when a particular functionality or set of features have been implemented. This talk argues that time based release management acts as an effective coordination mechanism in large volunteer projects and shows examples from seven projects that have moved to time based releases: Debian, GCC, GNOME, Linux, OpenOffice, Plone, and X.org. > Some questions: > > - Will there be a period before the release when only bug fixes are > merged? > > - Will there be a release candidate? Those two answer each other. If your 0.9.2 release turns out to have bugs, you can trivially cut a bugfix-only 0.9.2.1, 0.9.2.2, 0.9.2.3... as needed. Weekly even. So 0.9.2 being bug-free isn't that important. And it's actually just about impossible for you .0 to be bug-free, because you get 20 times as many testers for an actual release as you get for any snapshot, so they _will_ find new bugs. It's just about guaranteed. Also unless your stabilization period is a hard freeze preventing new development from going into the repository, then you'll be introducing new bugs while you try to fix 'em... > - Post-release, is there any interest in maintaining a stable branch > until the next release? That's kind of necessary for the previous two, but as long as it's clearly bugfix-only then it should have zero impact on new development, and can be done in a completely separate repository by a different maintainer. (That's how the linux kernel does things.) > - Is there any missing features that we might push out the release > date for? Defeats the purpose of time based releases: it's ok to bump things from this release if the next release is a finite amount of time away. If you have no idea when the next release will be, then getting every last feature into this release (and holding up the release for it) is a big deal, and thus you have endless delays, feature creep, a rush to merge things that aren't quite ready when a release is floated... > - The plan for the next release is roughly 6 months, yes? The general theory of having regular scheduled releases is that bumping stuff until the next release is no longer the end of the world, because there _will_ be a next release, and this has lots and lots of positive side effects, as described in the video. > Thanks, > Mark. Rob