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.