From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fD57a-0005GZ-MH for qemu-devel@nongnu.org; Mon, 30 Apr 2018 05:29:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fD57W-0007wj-NC for qemu-devel@nongnu.org; Mon, 30 Apr 2018 05:29:22 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:58698 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fD57W-0007wV-IV for qemu-devel@nongnu.org; Mon, 30 Apr 2018 05:29:18 -0400 Date: Mon, 30 Apr 2018 11:29:06 +0200 From: Cornelia Huck Message-ID: <20180430112906.20101672.cohuck@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] release retrospective, next release timing, numbering List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Stefan Hajnoczi On Fri, 27 Apr 2018 16:51:03 +0100 Peter Maydell wrote: > Hi; I usually let people forget about releases for a month or > so before bringing this topic up, but: > > (1) do we want to call the next release 2.13, or something else? > There's no particular reason to bump to 3.0 except some combination of > * if we keep going like this we'll get up to 2.42, which starts to > get silly > * Linus-style "avoid being too predictable" > * triskaidekaphobia * avoiding that this discussion comes up every release :) > but maybe we should anyway? v3.0 sounds fine to me. > > (2) release timing: > * usual schedule would give us a next release mid-to-late August > * unless I can persuade Stefan to do the release management this > cycle we might need to wind that in by a couple of weeks so > it's definitely done by the middle of August, to avoid a clash > with a personal commitment > * so probably hardfreeze 10th July, softfreeze 3rd July August might be more of a vacation month than July, anyway? (Depending on where you live, I guess.) No objection from me. > > (3) retrospective, lessons learned &c > * please remember that if every single submaintainer submits > a pull request on the morning of an RC, it is physically > not possible for me to process all those pulls in time to > tag the RC that day. We had several RCs which got delayed > by a day because of this; please try to submit earlier > rather than later... There seemed to have been several 'oh crap' issues that people wanted to get in asap, so that might account for it. On a related note: During the development phase, does it make more sense to collect stuff until you have a big pile of patches, or is it better (from an integration perspective) to do more frequent, smaller pull requests? > * provide your opinions here ? > > thanks > -- PMM >