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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
