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. -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list