From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [RFC] QEMU 2.10 release schedule
Date: Wed, 31 May 2017 16:18:41 +0100 [thread overview]
Message-ID: <87zidtrr5a.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA-AjqsFnk8O3vVO-zhWwowfgZuJi0PWgezPO6K-Ye2cqw@mail.gmail.com>
Peter Maydell <peter.maydell@linaro.org> writes:
> On 30 May 2017 at 11:11, Stefan Hajnoczi <stefanha@gmail.com> wrote:
>> Here is a first stab at the next release schedule:
>>
>> Beginning of development phase: 2017-04-20
>> Soft feature freeze: 2017-07-18
>> -rc0: 2017-07-25
>> -rc1: 2017-08-01
>> -rc2: 2017-08-08
>> -rc3: 2017-08-15
>> -rc4: 2017-08-22
>
> Are we going with the same definitions of soft/hard freeze
> as last time around?
>
> (I thought last release was a complete mess in terms of
> getting code in in an orderly manner for the freeze,
> personally...)
Do we want to have a broad plan for the order things need to go in
before the feature freeze or stick to a first to the gate approach?
Obviously we don't want to stall the process waiting for delayed series
that might end up getting dropped but having the broad sketches might
make it easier for developers to prioritise what patches queues to drain
first?
--
Alex Bennée
next prev parent reply other threads:[~2017-05-31 15:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-30 10:11 [Qemu-devel] [RFC] QEMU 2.10 release schedule Stefan Hajnoczi
2017-05-30 11:07 ` Paolo Bonzini
2017-05-30 11:21 ` Christian Borntraeger
2017-05-31 13:06 ` Stefan Hajnoczi
2017-06-07 18:24 ` Marc-André Lureau
2017-06-08 10:13 ` Stefan Hajnoczi
2017-05-31 14:25 ` Peter Maydell
2017-05-31 15:18 ` Alex Bennée [this message]
2017-06-08 10:14 ` Stefan Hajnoczi
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=87zidtrr5a.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=borntraeger@de.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/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.