From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhDoe-0002iV-QO for qemu-devel@nongnu.org; Tue, 06 Sep 2016 06:41:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhDoZ-0006B8-Mm for qemu-devel@nongnu.org; Tue, 06 Sep 2016 06:41:19 -0400 Received: from mail-vk0-x22f.google.com ([2607:f8b0:400c:c05::22f]:34152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhDoZ-0006Ar-Ir for qemu-devel@nongnu.org; Tue, 06 Sep 2016 06:41:15 -0400 Received: by mail-vk0-x22f.google.com with SMTP id v189so96299805vkv.1 for ; Tue, 06 Sep 2016 03:41:15 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160906103311.GA4667@noname.redhat.com> References: <20160906103311.GA4667@noname.redhat.com> From: Peter Maydell Date: Tue, 6 Sep 2016 11:40:54 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] proposed release timetable for 2.8 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: QEMU Developers , Stefan Hajnoczi On 6 September 2016 at 11:33, Kevin Wolf wrote: > Am 05.09.2016 um 13:10 hat Peter Maydell geschrieben: >> 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. We already do (informally) once we're a way into the hard freeze. Bug reports (and fixes for them) arrive all the time, and at a rate such that if we allowed any bug fix into the tree during freeze we would never have a period of a week without new bugfixes going in that allowed us to actually release. If a bug went unnoticed and unfixed for almost the whole release cycle, this is a good sign that it's actually not all that prominent to users; so it's a reasonably good, objective, and easy to apply metric for restricting bug fixes to "only important bug fixes". thanks -- PMM