[libvirt] Upcoming 0.6.2 release
Mark McLoughlin
markmc at redhat.com
Tue Mar 31 09:52:46 UTC 2009
On Fri, 2009-03-27 at 18:49 +0100, Daniel Veillard wrote:
> I would suggest the following:
> - I post every week, say at the end of the week when I think the
> next releases will be likely to occur, trying to refine as we get
> closer
> - We try to not make any release if there isn't a 2 week advance
> warning
> - we try to get everything commited one week before the release
> as to get some kind of feature freeze one week in advance for
> testing as Dan requested and yes this really make sense
I think this is a great improvement - it makes things much more
predictable, it means not getting a feature into a given release isn't a
big deal because the next one isn't far away and it gives some chance
for features to settle down before a release.
Monthly releases is very aggressive for a big project. I worry that
since each release may have significant new features which have had only
one week of testing, people will never be able to have a lot of
confidence in any libvirt release.
e.g. I can imagine a situation in Fedora where libvirt-0.9.0 is released
and we decide we want to push that as an update to Fedora 14. After a
few weeks of people testing, we'd probably have found a bunch of bugs
and backported the fixes from upstream. Then, just as things start to
settle down, 0.9.1 is released with a bunch of new features and fixes,
but we find that also has a bunch of bugs that takes a few weeks to iron
out. And, then again for 0.9.2.
With monthly releases containing new features, I think it's worthwhile
also doing "bugfix only" releases. Maybe 2-3 weeks after a release,
cherry-pick fixes from HEAD into a stable branch and do a release of
that.
I took a quick stab at creating a 0.6.1.y branch with bugfixes from
HEAD, to take a look:
$> git clone http://markmc.fedorapeople.org/git/libvirt-0.6.1.y.git/
$> cd libvirt-0.6.1.y.git
$> git log LIBVIRT_0_6_1..
There's nothing shocking here. Since 0.6.1 it's been mostly bug fixes,
so all I've left out is:
- qemu ballooning
- SASL auth support
- more flexibility about qemu emulators
- posix_fallocate()
- lxc CPU usage
- compiler warnings, syntax-check improvement
- test driver fix
Still, though, that makes a big difference to the diffstat. On CVS HEAD
since 0.6.1 we've had:
52 files changed, 994 insertions(+), 288 deletions(-)
this bugfix branch only has:
20 files changed, 169 insertions(+), 118 deletions(-)
Compare that to our backported fixes for 0.6.1 in Fedora rawhide:
14 files changed, 142 insertions(+), 109 deletions(-)
I'm waffling a bit, but in summary:
- Good plan, but monthly releases with a one week feature freeze will
inevitably mean some significant bugs in each release
- Not everyone wants to be on the bleeding edge - some people do want
some stability
- A pure bugfix is very easy to prepare by cherry-picking from HEAD
onto a branch (it took me ~30 minutes)
- Distros already backport fixes - this helps them out
- Stable releases are fairly standard practice for most projects
Cheers,
Mark.
More information about the libvir-list
mailing list