All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] proposed release timetable for 2.8
Date: Wed, 14 Sep 2016 15:27:55 +0100	[thread overview]
Message-ID: <20160914142755.GC16438@stefanha-x1.localdomain> (raw)
In-Reply-To: <CAFEAcA9Hxac3VEGFcq2QNAXAwvsZu=cg+vWbTVD6q0zxdx452Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

On Mon, Sep 05, 2016 at 04:11:43PM +0100, Peter Maydell wrote:
> On 5 September 2016 at 15:47, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > 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.
> 
> I think there is a difference for developers, because our
> current definition (http://wiki.qemu.org/Planning/SoftFeatureFreeze)
> says that "non-trivial features should have code posted to the list".
> If you want feature pull reqs to be onlist by the softfreeze date
> then that means developers need to get their patches onlist (and
> indeed through code review) earlier.
> 
> So for practical purposes I don't think it makes much difference:
> if you're a dev trying to get a feature into 2.8 then you will
> need to get it all code reviewed and into the maintainer's tree
> about a week earlier than under our current longer schedule with
> a more relaxed attitude to late-feature-stuff. Describing it
> all this way might be clearer to everybody about when stuff needs
> to be done, though.

Sound good.  That's why I made a distinction between hard freeze and
-rc0.  If maintainers are still sending significant pull requests up
until the hard freeze deadline then the chance of merging them and
releasing an -rc0 on the same day are slim.

If we're stricter and say that soft freeze is the deadline for feature
pull requests from maintainers then tagging an -rc0 is easy because
there will be way less churn.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  parent reply	other threads:[~2016-09-14 14:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-01 11:18 [Qemu-devel] proposed release timetable for 2.8 Peter Maydell
2016-09-01 14:08 ` Stefan Hajnoczi
2016-09-05  9:38   ` Kevin Wolf
2016-09-05 18:20     ` Stefan Hajnoczi
2016-09-05 14:47   ` Paolo Bonzini
2016-09-05 15:11     ` Peter Maydell
2016-09-05 15:15       ` Paolo Bonzini
2016-09-14 14:27       ` Stefan Hajnoczi [this message]
2016-09-06  2:43     ` Michael S. Tsirkin
2016-09-06  7:52       ` Paolo Bonzini
2016-09-05 11:10 ` Peter Maydell
2016-09-05 12:09   ` Markus Armbruster
2016-09-06 10:33   ` Kevin Wolf
2016-09-06 10:40     ` Peter Maydell
2016-09-06 12:40       ` Markus Armbruster
2016-09-06 12:43         ` Peter Maydell
2016-09-05 12:34 ` Daniel P. Berrange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160914142755.GC16438@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.