On 05/17/2017 05:34 PM, Chris Jones wrote:
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).
I welcome projects to experiment with it, but strong -1 to make it any
kinds of policy. Actually, we mostly got rid of the feature freeze in
Ironic because of how it did not work for us.
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.
6 weeks of each release is not enough to land anything serious IMO. Most
of big feature I remember took months of review to land.
Also what this is going to end up with is folks working on features
during the freeze with -2 applied. And then in these 6 weeks they'll put
*enormous* pressure on the core team to merge their changes, knowing
that otherwise they'll have to wait 5 months more.
Even our regular feature freeze had this effect to some extent. People
don't plan that early, not all code patches are of equal quality
initially, etc. While you can blame them for it (and you'll probably be
right), this will still end up in core team pressurized.
This will also make prioritization much more difficult, as a feature
that was not deemed a priority is unlikely to land at all. We already
have complaints from some contributors about uneven prioritization, your
proposal has chances of making it much worse.
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.
From our experience, most of the non-core developers just go away during
the feature freeze, and come back when it's lifted. I don't remember any
increase in the number of bugs fixed during that time frame. Most of the
folks not deploying from master still start serious testing after the GA.
And this proposal may make it harder for people to justify full-time
work on a certain projects.
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.
It may differ per project. We have enough time, we don't have enough
people testing and fixing bugs before the GA.
As an alternative, I'd prefer people to work with stable branches more
actively. And deploy a kind of CI/CD system that will allow them to test
code at any point in time, not only close to the release.
--
Cheers,
Chris
__________________________________________________________________________
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
