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

[Kevin Wolf <kwolf@redhat.com>]

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