From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:54370)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1bgrnn-0003td-G8
	for qemu-devel@nongnu.org; Mon, 05 Sep 2016 07:11:00 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1bgrnl-000243-E2
	for qemu-devel@nongnu.org; Mon, 05 Sep 2016 07:10:58 -0400
Received: from mail-vk0-x22e.google.com ([2607:f8b0:400c:c05::22e]:33073)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1bgrnk-00023t-KM
	for qemu-devel@nongnu.org; Mon, 05 Sep 2016 07:10:57 -0400
Received: by mail-vk0-x22e.google.com with SMTP id f76so74385875vke.0
	for <qemu-devel@nongnu.org>; Mon, 05 Sep 2016 04:10:56 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <CAFEAcA9J6Yxqqeg+BzEjNJfuX1Zr93i3797J+3QD-HXHMANUew@mail.gmail.com>
References: <CAFEAcA9J6Yxqqeg+BzEjNJfuX1Zr93i3797J+3QD-HXHMANUew@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Mon, 5 Sep 2016 12:10:35 +0100
Message-ID: <CAFEAcA97PvZbqGoF2AqZzfEb7L2Yadi9retmPyxT7JWK2VFYww@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Qemu-devel] proposed release timetable for 2.8
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: QEMU Developers <qemu-devel@nongnu.org>
Cc: Stefan Hajnoczi <stefanha@redhat.com>

On 1 September 2016 at 12:18, Peter Maydell <peter.maydell@linaro.org> 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?

thanks
-- PMM