qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] proposed release timetable for 2.8
Date: Wed, 14 Sep 2016 15:27:55 +0100
User-agent: Mutt/1.7.0 (2016-08-17)

On Mon, Sep 05, 2016 at 04:11:43PM +0100, Peter Maydell wrote:
> On 5 September 2016 at 15:47, Paolo Bonzini <address@hidden> 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: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]