From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgvB9-0004fT-F7 for qemu-devel@nongnu.org; Mon, 05 Sep 2016 10:47:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgvB5-00066P-B8 for qemu-devel@nongnu.org; Mon, 05 Sep 2016 10:47:18 -0400 Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:34821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgvB5-00066I-2U for qemu-devel@nongnu.org; Mon, 05 Sep 2016 10:47:15 -0400 Received: by mail-wm0-x22d.google.com with SMTP id w2so125571831wmd.0 for ; Mon, 05 Sep 2016 07:47:14 -0700 (PDT) Sender: Paolo Bonzini References: <20160901140823.GA24262@stefanha-x1.localdomain> From: Paolo Bonzini Message-ID: Date: Mon, 5 Sep 2016 16:47:11 +0200 MIME-Version: 1.0 In-Reply-To: <20160901140823.GA24262@stefanha-x1.localdomain> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] proposed release timetable for 2.8 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , Peter Maydell Cc: QEMU Developers On 01/09/2016 16:08, Stefan Hajnoczi wrote: > I suggest we do the schedule above with a firm hardfreeze deadline where > no more feature pull requests are allowed. This means a 2 week > softfreeze and time before -rc0 for the maintainer to merge and test > pull requests: > > 2016-10-25 softfreeze > 2016-11-08 hardfreeze > 2016-11-15 rc0 > 2016-11-22 rc1 > 2016-11-29 rc2 > 2016-12-06 rc3 > 2016-12-13 final v2.8.0 I don't think there is much advantage in delaying rc0 past hard freeze, since hard freeze is the time when feature pull requests are not merged even if posted on list. Based also on the discussion at QEMU summit, where there was consensus that three weeks between softfreeze and rc0 was too much, IMO we can shorten the period to just two weeks * softfreeze is a deadline for _maintainers_ to post their large pull requests. Developers are unaffected, except that the maintainers will be stricter. * hardfreeze as the rc0 date as before, with two weeks This would give, based on Peter's 2 week softfreeze schedule: 2016-11-01 softfreeze - v1 posted for all feature pull requests ... time for solving conflicts, build issues, etc. ... 2016-11-15 hardfreeze+rc0 2016-11-22 rc1 2016-11-29 rc2 2016-12-06 rc3 2016-12-13 rc4 or release 2016-12-20 delayed release if rc4 was necessary This still leaves almost two weeks of margin before Christmas. Thanks, Paolo