Hey Well, it definitely seems like there's not much support for the idea ;)
Thanks everyone who replied. I'll go away and think about ways we can improve things without moving FF :) Cheers, -- Chris Jones > On 18 May 2017, at 11:18, Thierry Carrez <thie...@openstack.org> wrote: > > Chris Jones wrote: >> I have a fairly simple proposal to make - I'd like to suggest that >> Feature Freeze move to being much earlier in the release cycle (no >> earlier than M.1 and no later than M.2 would be my preference). >> [...] > > Hey Chris, > > From my (admittedly too long) experience in release management, forcing > more time for stabilization work does not magically yield better > results. There is nothing like a "perfect" release, it's always a "good > enough" trade-off. Holding releases in the hope that more bugs will be > discovered and fixed only works so far: some bugs will only emerge once > people start deploying software in their unique environments and use > cases. It's better to put it out there when it's "good enough". > > So a Feature Freeze should be placed early enough to give you an > opportunity to slow down, fix known blockers, have documentation and > translations catch up. Currently that means 5-6 weeks. Moving it earlier > than this reasonable trade-off just brings more pain for little benefit. > It is hard enough to get people to stop pushing features and feature > freeze exceptions and do stabilization work for 5 weeks. Forcing a > longer freeze would just see an explosion of local feature branches, not > a more "stable" release. > > Furthermore, we have a number of projects (newly-created ones that need > to release early, or mature ones that want to push that occasional new > feature more often) that bypass the feature freeze / RC system > completely. With more constraints, I'd expect most projects to switch to > that model instead. > >> Rather than getting hung up on the specific numbers of weeks, perhaps it >> would be helpful to start with opinions on whether or not there is >> enough stabilisation time in the current release schedules. > > Compared to the early days of OpenStack (where we'd still use a 5-6-week > freeze period) our automated testing has come a long way. The cases > where we need to respin release candidates due to a major blocker that > was not caught in automated testing are becoming rarer. If anything, the > data points to a need for shorter freezes rather than longer ones. The > main reason we are still at 5-6weeks those days is for translations and > docs, rather than real stabilization work. I'm not advocating for making > it shorter, I still think it's the right trade-off :) > > -- > Thierry Carrez (ttx) > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev