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