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

[Stefan Hajnoczi]

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

signature.asc
Description: PGP signature