From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhDgs-0005Dn-Um for qemu-devel@nongnu.org; Tue, 06 Sep 2016 06:33:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhDgo-00048q-55 for qemu-devel@nongnu.org; Tue, 06 Sep 2016 06:33:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhDgo-00048Z-02 for qemu-devel@nongnu.org; Tue, 06 Sep 2016 06:33:14 -0400 Date: Tue, 6 Sep 2016 12:33:11 +0200 From: Kevin Wolf Message-ID: <20160906103311.GA4667@noname.redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Am 05.09.2016 um 13:10 hat Peter Maydell geschrieben: > On 1 September 2016 at 12:18, 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. > > It occurs to me that if anybody has the patience to do some tedious > data-mining, it would be interesting to know for all the commits > that went in after rc0 whether they were: > * fixing bugs that were already present in our previous release > * fixing regressions (ie bugs introduced after the previous release) > * fixing bugs in features that are new in this release > * new features > * fixing bugs introduced by other post-rc0 commits > * security fixes > > ie if we were stricter about "no commits unless they're fixes for > regressions, fixes for things new in this release or security fixes", > would this reduce the number of commits we do post-freeze much? I don't think we should leave a bug intentionally unfixed even though there is a patch, just because it was already broken in the last release. Kevin