Re: [libvirt] Upcoming 0.6.2 release
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.