On Fri, Mar 27, 2009 at 7:05 AM, Daniel P. Berrange <berrange@redhat.com>wrote:

Our release schedule has become a little too variable in timeframe and quality in recent times. We've tended to get into a situation where we've had some very large new features going in very late before release with little time for actually testing them between commit & release. It is unrealistic to expect pre-commit reviews to catch all problems, so I think it might be worth us setting out a very slightly more formal rule for commit/release schedule.

I'd like to suggest:

- Monthly releases aiming for 1st of the month (plus/minus 3 days to take into account weekends/holidays)

- Any non-trivial new feature for release must be reviewed, approved and committed at least 1 week before the release. eg by 24th of each month

This will give people using libvirt CVS some time to sanity check new features aren't causing serious regressions / crashes before we release.

<<snip>>

Daniel

+1 on release schedule. This still gives the project speed and flexibility, while reducing the risks of new features or big changes breaking the release. Just my $0.03. (US Inflation, y'know) -Richard Balint

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.