[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Cutting a new QEMU release
From: |
Rob Landley |
Subject: |
Re: [Qemu-devel] Cutting a new QEMU release |
Date: |
Mon, 9 Feb 2009 18:47:37 -0600 |
User-agent: |
KMail/1.10.1 (Linux/2.6.27-9-generic; KDE/4.1.2; x86_64; ; ) |
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