Re: [Qemu-devel] Cutting a new QEMU release

[Rob Landley]

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