Re: [Qemu-devel] proposed release timetable for 2.8

[Daniel P. Berrange]

On Thu, Sep 01, 2016 at 12:18:10PM +0100, Peter Maydell wrote:
> I know 2.7 isn't quite out the door yet, but I figured we should
> kick off the discussion of 2.8's schedule. At the QEMU Summit there
> was some discussion on how we're doing with releases, and I think
> the consensus view was that we should try to cut down the softfreeze
> period and also be stricter about (a) making sure pull requests get
> in in a timely way before rc0 and (b) we don't take new features
> during softfreeze.
> 
> (I'm not entirely sure I have those right, and in any case they're
> not pre-decided conclusions, so corrections and further opinion
> welcome.)
> 
> As a strawman, here's a timetable which results in a final
> release in December at the usual sort of time (ie allowing for
> the usual slippage without it hitting the holiday season):
> 
> 
> 2016-10-25 softfreeze, if you think we need 3 weeks, or:
> 2016-11-01 if you think we can do a 2 week softfreeze
> 2016-11-08 deadline for getting pull requests on list before hardfreeze?
> 2016-11-15 rc0 (start of hardfreeze)
> 2016-11-22 rc1
> 2016-11-29 rc2
> 2016-12-06 rc3
> 2016-12-13 final v2.8.0

So, for sake of simplicity, lets assume GIT master opens for 2.8
tomorrow. If I'm counting right, with a 3 week softfreeze, that
would give us 7 weeks of master being open for feature merges,
followed by 7 weeks of master being open for bug fixes only. If
we did a 2 week softfreeze, the split would be 8 weeks feature,
6 weeks bugfix.

IME, the longer the time period when features cannot be accepted
into master, the more instability there is when they're finally
merged, as you get a bigger burst of stuff merging immediately
post release. The longer the freeze time is, the larger the penalty
is for not getting your code merged in time which in turn makes people
more inclined rush to get stuff merged and then worry about fixing
the inevitable problems during freeze. IOW a freeze that's too long
can actually be counterproductive to stability overall. So it is worth
considering whether the time split of dev cycle is right.

Personally I think a 7 week / 7 week split (from the 3 week soft
freeze) is probably setting aside too much time for freeze overall,
and counterproductive to quality by encouraging people to rush stuff
in to beat the freeze. I think it is worth considering if the 2 week
soft freeze option is possible, to give a 8 week / 6 week split overall.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|