Open Stack

Hey folks

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).

In the current arrangement (looking specifically at Pike), FF is scheduled
to happen 5 weeks before the upstream release. This means that of a 26 week
release cycle, 21 weeks are available for making large changes, and only 5
weeks are available for stabilising the release after the feature work has
landed (possibly less if FF exceptions are granted).

In my experience, significant issues are generally still being found after
the upstream release, by which point fixing them is much harder - the
patches need to land twice (master and stable/foo) and master may already
have diverged.

If the current model were inverted, and ~6 weeks of each release were
available for landing features, there would be ~20 weeks available for
upstream and downstream folk to do their testing/stabilising work. The
upstream release ought to have a higher quality, and downstream releases
would be more likely to be able to happen at the same time.

Obviously not all developers would be working on the stabilisation work for
those ~20 weeks, many would move on to working on features for the
following release, which would then be ready to land in the much shorter
period.

This might slow the feature velocity of projects, and maybe ~6 weeks is too
aggressive, but I feel that the balance right now is weighted strongly
against timely, stable releasing of OpenStack, particularly for downstream
consumers :)

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.

-- 
Cheers,

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170517/f42493c4/attachment.html>