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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
