Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>