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