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
