On Tue, Sep 29, 2009 at 05:06:46PM +0200, Daniel Veillard wrote:
On Tue, Sep 29, 2009 at 03:29:49PM +0100, Daniel P. Berrange wrote:
> I think it would be nice to get back on an end-of-the-month release
> schedule. It was nice to have predictability that the date was approx
> the 30/31st of the month. If we did two 5 week cycles instead of 4
> week cycles we'd be trivially aligned again, Fri 23 Oct and then
> Fri 27 Nov, etc
Hum, understood but I would prefer 2 releases than one big one, so
what about
9/10 code freeze for 0.7.2
16/10 release of 0.7.2
23/10 code freeze for 0.7.3
30/10 release of 0.7.3
this mean a bit more churn on the releases push but I prefer than than
waiting 6 weeks, I didn that the last time and IMHO that was too long.
And that should not block development too much, if by the 9 some feature
is not ready keep it warm until after 0.7.2, unless there is really a
set of dependant changes, the intermediate week of bug fixes should not
really affect productivity, right ?
Okay, my take on this is that we should basically enter a small
testing and doc/cleanups/bugfixes only commit in the next days for the
0.7.2 release, but to avoid too much impedance on the development cycle
and since 0.7.3 is slated for the end of the month, I would suggest to
release 0.7.2 mid next week instead of waiting a full week (unless
testing proves that we need more time to fix crucial bugs). On the other
hand the 0.7.3 would get the full week of bug fixes and testing at the
end of the month.
So I will probably push 0.7.2 on Wednesday and reopen the gate for
commits on that day, minimizing the impact of that extra release.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/