[Qemu-devel] proposed release timetable for 2.8

[Qemu-devel] proposed release timetable for 2.8

[Peter Maydell]

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.

(I'm not entirely sure I have those right, and in any case they're
not pre-decided conclusions, so corrections and further opinion
welcome.)

As a strawman, here's a timetable which results in a final
release in December at the usual sort of time (ie allowing for
the usual slippage without it hitting the holiday season):


2016-10-25 softfreeze, if you think we need 3 weeks, or:
2016-11-01 if you think we can do a 2 week softfreeze
2016-11-08 deadline for getting pull requests on list before hardfreeze?
2016-11-15 rc0 (start of hardfreeze)
2016-11-22 rc1
2016-11-29 rc2
2016-12-06 rc3
2016-12-13 final v2.8.0

I haven't been particularly happy with the 2.7 release process,
which has dragged on a lot due to some combination of:
 * late-breaking security issues
 * KVM Forum timing (we were optimistic about getting the
   release out beforehand and didn't manage it)
 * a bunch of bugs either discovered late or without patches
   on list and in tree very quickly
I'm not sure how best to improve things though.

Side note: I will not be around for most of November so
Stefan has kindly agreed to manage the merging and tagging
work this time around.

thanks
-- PMM

Re: [Qemu-devel] proposed release timetable for 2.8

[Stefan Hajnoczi]

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

On Thu, Sep 01, 2016 at 12:18:10PM +0100, 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.
> 
> (I'm not entirely sure I have those right, and in any case they're
> not pre-decided conclusions, so corrections and further opinion
> welcome.)
> 
> As a strawman, here's a timetable which results in a final
> release in December at the usual sort of time (ie allowing for
> the usual slippage without it hitting the holiday season):
> 
> 
> 2016-10-25 softfreeze, if you think we need 3 weeks, or:
> 2016-11-01 if you think we can do a 2 week softfreeze
> 2016-11-08 deadline for getting pull requests on list before hardfreeze?
> 2016-11-15 rc0 (start of hardfreeze)
> 2016-11-22 rc1
> 2016-11-29 rc2
> 2016-12-06 rc3
> 2016-12-13 final v2.8.0

I suggest we do the schedule above with a firm hardfreeze deadline where
no more feature pull requests are allowed.  This means a 2 week
softfreeze and time before -rc0 for the maintainer to merge and test
pull requests:

2016-10-25 softfreeze
2016-11-08 hardfreeze
2016-11-15 rc0
2016-11-22 rc1
2016-11-29 rc2
2016-12-06 rc3
2016-12-13 final v2.8.0

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

Re: [Qemu-devel] proposed release timetable for 2.8

[Kevin Wolf]

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

Am 01.09.2016 um 16:08 hat Stefan Hajnoczi geschrieben:
> On Thu, Sep 01, 2016 at 12:18:10PM +0100, 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.
> > 
> > (I'm not entirely sure I have those right, and in any case they're
> > not pre-decided conclusions, so corrections and further opinion
> > welcome.)
> > 
> > As a strawman, here's a timetable which results in a final
> > release in December at the usual sort of time (ie allowing for
> > the usual slippage without it hitting the holiday season):
> > 
> > 
> > 2016-10-25 softfreeze, if you think we need 3 weeks, or:
> > 2016-11-01 if you think we can do a 2 week softfreeze
> > 2016-11-08 deadline for getting pull requests on list before hardfreeze?
> > 2016-11-15 rc0 (start of hardfreeze)
> > 2016-11-22 rc1
> > 2016-11-29 rc2
> > 2016-12-06 rc3
> > 2016-12-13 final v2.8.0
> 
> I suggest we do the schedule above with a firm hardfreeze deadline where
> no more feature pull requests are allowed.  This means a 2 week
> softfreeze and time before -rc0 for the maintainer to merge and test
> pull requests:
> 
> 2016-10-25 softfreeze
> 2016-11-08 hardfreeze
> 2016-11-15 rc0
> 2016-11-22 rc1
> 2016-11-29 rc2
> 2016-12-06 rc3
> 2016-12-13 final v2.8.0

The major difference to the current process is here really that we don't
do a -rc0 release any more. What you called -rc0 is really what used to
be -rc1, i.e. a proper release candidate release where some testing and
stabilisation has already happened.

Though we'll probably not get quite as much testing as if we kept
releasing an actual tarball as a hardfreeze snapshot (which is what -rc0
used to be rather than a proper release candidate.)

Has -rc0 been particularly painful from a maintainer POV, or what is the
reason for dropping it?

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [Qemu-devel] proposed release timetable for 2.8

[Stefan Hajnoczi]

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

On Mon, Sep 05, 2016 at 11:38:06AM +0200, Kevin Wolf wrote:
> Am 01.09.2016 um 16:08 hat Stefan Hajnoczi geschrieben:
> > On Thu, Sep 01, 2016 at 12:18:10PM +0100, 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.
> > > 
> > > (I'm not entirely sure I have those right, and in any case they're
> > > not pre-decided conclusions, so corrections and further opinion
> > > welcome.)
> > > 
> > > As a strawman, here's a timetable which results in a final
> > > release in December at the usual sort of time (ie allowing for
> > > the usual slippage without it hitting the holiday season):
> > > 
> > > 
> > > 2016-10-25 softfreeze, if you think we need 3 weeks, or:
> > > 2016-11-01 if you think we can do a 2 week softfreeze
> > > 2016-11-08 deadline for getting pull requests on list before hardfreeze?
> > > 2016-11-15 rc0 (start of hardfreeze)
> > > 2016-11-22 rc1
> > > 2016-11-29 rc2
> > > 2016-12-06 rc3
> > > 2016-12-13 final v2.8.0
> > 
> > I suggest we do the schedule above with a firm hardfreeze deadline where
> > no more feature pull requests are allowed.  This means a 2 week
> > softfreeze and time before -rc0 for the maintainer to merge and test
> > pull requests:
> > 
> > 2016-10-25 softfreeze
> > 2016-11-08 hardfreeze
> > 2016-11-15 rc0
> > 2016-11-22 rc1
> > 2016-11-29 rc2
> > 2016-12-06 rc3
> > 2016-12-13 final v2.8.0
> 
> The major difference to the current process is here really that we don't
> do a -rc0 release any more. What you called -rc0 is really what used to
> be -rc1, i.e. a proper release candidate release where some testing and
> stabilisation has already happened.
> 
> Though we'll probably not get quite as much testing as if we kept
> releasing an actual tarball as a hardfreeze snapshot (which is what -rc0
> used to be rather than a proper release candidate.)
> 
> Has -rc0 been particularly painful from a maintainer POV, or what is the
> reason for dropping it?

With the build testing and continuous integration that is done nowadays,
is there even such a thing as a snapshot without testing and
stabilization?

Even bug fixes during hard freeze can introduce new bugs.  My perception
is that Peter gets bombarded with pull requests at the end of hard
freeze, making it difficult to tag a release candidate in a timely
manner.

Stefan


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

Re: [Qemu-devel] proposed release timetable for 2.8

[Paolo Bonzini]

On 01/09/2016 16:08, Stefan Hajnoczi wrote:
> I suggest we do the schedule above with a firm hardfreeze deadline where
> no more feature pull requests are allowed.  This means a 2 week
> softfreeze and time before -rc0 for the maintainer to merge and test
> pull requests:
> 
> 2016-10-25 softfreeze
> 2016-11-08 hardfreeze
> 2016-11-15 rc0
> 2016-11-22 rc1
> 2016-11-29 rc2
> 2016-12-06 rc3
> 2016-12-13 final v2.8.0

I don't think there is much advantage in delaying rc0 past hard freeze,
since hard freeze is the time when feature pull requests are not merged
even if posted on list.

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.

* hardfreeze as the rc0 date as before, with two weeks

This would give, based on Peter's 2 week softfreeze schedule:

2016-11-01 softfreeze - v1 posted for all feature pull requests
	... time for solving conflicts, build issues, etc. ...
2016-11-15 hardfreeze+rc0
2016-11-22 rc1
2016-11-29 rc2
2016-12-06 rc3
2016-12-13 rc4 or release
2016-12-20 delayed release if rc4 was necessary

This still leaves almost two weeks of margin before Christmas.

Thanks,

Paolo

Re: [Qemu-devel] proposed release timetable for 2.8

[Peter Maydell]

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.

thanks
-- PMM

Re: [Qemu-devel] proposed release timetable for 2.8

[Paolo Bonzini]

On 05/09/2016 17:11, Peter Maydell 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".
> [...] 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.

I agree.

Paolo

Re: [Qemu-devel] proposed release timetable for 2.8

[Stefan Hajnoczi]

[-- 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 --]

Re: [Qemu-devel] proposed release timetable for 2.8

[Michael S. Tsirkin]

On Mon, Sep 05, 2016 at 04:47:11PM +0200, Paolo Bonzini wrote:
> 
> 
> On 01/09/2016 16:08, Stefan Hajnoczi wrote:
> > I suggest we do the schedule above with a firm hardfreeze deadline where
> > no more feature pull requests are allowed.  This means a 2 week
> > softfreeze and time before -rc0 for the maintainer to merge and test
> > pull requests:
> > 
> > 2016-10-25 softfreeze
> > 2016-11-08 hardfreeze
> > 2016-11-15 rc0
> > 2016-11-22 rc1
> > 2016-11-29 rc2
> > 2016-12-06 rc3
> > 2016-12-13 final v2.8.0
> 
> I don't think there is much advantage in delaying rc0 past hard freeze,
> since hard freeze is the time when feature pull requests are not merged
> even if posted on list.
> 
> 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

Do we intend to strengthen the soft freeze definition then?
One difficulty is that the definition for soft freeze at the moment is
that some code is on list.  Some of these get reworked significantly.

I get flooded with patches just before the softfreeze, all conflicting,
all need some work, and it takes a bunch of back and forth to resolve
the conflicts.

> * softfreeze is a deadline for _maintainers_ to post their large pull
> requests.  Developers are unaffected, except that the maintainers will
> be stricter.
> 
> * hardfreeze as the rc0 date as before, with two weeks
> 
> This would give, based on Peter's 2 week softfreeze schedule:
> 
> 2016-11-01 softfreeze - v1 posted for all feature pull requests
> 	... time for solving conflicts, build issues, etc. ...
> 2016-11-15 hardfreeze+rc0
> 2016-11-22 rc1
> 2016-11-29 rc2
> 2016-12-06 rc3
> 2016-12-13 rc4 or release
> 2016-12-20 delayed release if rc4 was necessary
> 
> This still leaves almost two weeks of margin before Christmas.
> 
> Thanks,
> 
> Paolo

Re: [Qemu-devel] proposed release timetable for 2.8

[Paolo Bonzini]

On 06/09/2016 04:43, Michael S. Tsirkin 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
> 
> Do we intend to strengthen the soft freeze definition then?
> One difficulty is that the definition for soft freeze at the moment is
> that some code is on list.  Some of these get reworked significantly.

Yes, see Peter's answer to me.

> I get flooded with patches just before the softfreeze, all conflicting,
> all need some work, and it takes a bunch of back and forth to resolve
> the conflicts.

You are too good! :)

Paolo

Re: [Qemu-devel] proposed release timetable for 2.8

[Peter Maydell]

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

Re: [Qemu-devel] proposed release timetable for 2.8

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

> 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?

Almost 300 commits to classify.  I'm afraid that's too tedious even for
me.

We could require such a classification for acceptance post 2.8-rc0.
Spreads the work.

Re: [Qemu-devel] proposed release timetable for 2.8

[Kevin Wolf]

Am 05.09.2016 um 13:10 hat Peter Maydell geschrieben:
> 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?

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

Re: [Qemu-devel] proposed release timetable for 2.8

[Peter Maydell]

On 6 September 2016 at 11:33, Kevin Wolf <kwolf@redhat.com> 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

Re: [Qemu-devel] proposed release timetable for 2.8

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 6 September 2016 at 11:33, Kevin Wolf <kwolf@redhat.com> 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".

In short, we use common sense to throttle the flow of bug fixes, so we
can get a release out of the door.

Re: [Qemu-devel] proposed release timetable for 2.8

[Peter Maydell]

On 6 September 2016 at 13:40, Markus Armbruster <armbru@redhat.com> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
>
>> On 6 September 2016 at 11:33, Kevin Wolf <kwolf@redhat.com> 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".
>
> In short, we use common sense to throttle the flow of bug fixes, so we
> can get a release out of the door.

Exactly. The question I was asking above can be rephrased as
"if we apply that throttling more strictly and sooner, would
we get a release faster?".

-- PMM

Re: [Qemu-devel] proposed release timetable for 2.8

[Daniel P. Berrange]

On Thu, Sep 01, 2016 at 12:18:10PM +0100, 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.
> 
> (I'm not entirely sure I have those right, and in any case they're
> not pre-decided conclusions, so corrections and further opinion
> welcome.)
> 
> As a strawman, here's a timetable which results in a final
> release in December at the usual sort of time (ie allowing for
> the usual slippage without it hitting the holiday season):
> 
> 
> 2016-10-25 softfreeze, if you think we need 3 weeks, or:
> 2016-11-01 if you think we can do a 2 week softfreeze
> 2016-11-08 deadline for getting pull requests on list before hardfreeze?
> 2016-11-15 rc0 (start of hardfreeze)
> 2016-11-22 rc1
> 2016-11-29 rc2
> 2016-12-06 rc3
> 2016-12-13 final v2.8.0

So, for sake of simplicity, lets assume GIT master opens for 2.8
tomorrow. If I'm counting right, with a 3 week softfreeze, that
would give us 7 weeks of master being open for feature merges,
followed by 7 weeks of master being open for bug fixes only. If
we did a 2 week softfreeze, the split would be 8 weeks feature,
6 weeks bugfix.

IME, the longer the time period when features cannot be accepted
into master, the more instability there is when they're finally
merged, as you get a bigger burst of stuff merging immediately
post release. The longer the freeze time is, the larger the penalty
is for not getting your code merged in time which in turn makes people
more inclined rush to get stuff merged and then worry about fixing
the inevitable problems during freeze. IOW a freeze that's too long
can actually be counterproductive to stability overall. So it is worth
considering whether the time split of dev cycle is right.

Personally I think a 7 week / 7 week split (from the 3 week soft
freeze) is probably setting aside too much time for freeze overall,
and counterproductive to quality by encouraging people to rush stuff
in to beat the freeze. I think it is worth considering if the 2 week
soft freeze option is possible, to give a 8 week / 6 week split overall.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|