[libvirt] Upcoming 0.6.2 release

[Mark McLoughlin]

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.