From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgt77-00054Q-Og for qemu-devel@nongnu.org; Mon, 05 Sep 2016 08:38:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgt6g-0001LS-LU for qemu-devel@nongnu.org; Mon, 05 Sep 2016 08:35:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60400) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgt6g-0001L9-Ch for qemu-devel@nongnu.org; Mon, 05 Sep 2016 08:34:34 -0400 Date: Mon, 5 Sep 2016 13:34:30 +0100 From: "Daniel P. Berrange" Message-ID: <20160905123430.GB24656@redhat.com> Reply-To: "Daniel P. Berrange" References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] proposed release timetable for 2.8 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Stefan Hajnoczi 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 :|