[openstack-dev] [release] Proposal to change the timing of Feature Freeze

Thierry Carrez thierry at openstack.org
Thu May 18 10:18:49 UTC 2017

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)

More information about the OpenStack-dev mailing list