Open Stack

On 5/17/2017 11:20 AM, Dmitry Tantsur wrote:
> 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
>>
>
>
> __________________________________________________________________________
> 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

Projects can impose their own freeze dates. For a long time Nova had a 
non-priority feature freeze after the 2nd milestone and then only worked 
on priority features during the last milestone and before the global 
feature freeze. The priorities were determined at the design summit.

Moving the feature freeze date up just puts a huge crunch on the core 
team to review everything, and it was coming shortly after the spec 
freeze (typically the first milestone for nova).

So people with non-priority changes were mad because they didn't get 
their stuff reviewed or merged before the non-priority FF, and people 
working on features felt that we didn't put enough focus on them 
throughout the entire release and would really just focus on those 
things in the last milestone.

There are pros/cons to each, but since Ocata Nova has just done a spec 
freeze at the first milestone and then global feature freeze at the 3rd 
milestone.

Arguably we should be focusing on bugs and stabilization at all points 
in the release, but in reality people are pushing for features and new 
changes and those are the loudest voices so it drowns out being able to 
spend time on fixing bugs and technical debt. And, with deployments 
being 12+ months behind trunk, a lot of times we don't even start seeing 
bug reports rolling in for things for a long time - like we're starting 
to see more Newton bugs showing up now that Mitaka is EOL and people are 
upgrading.

-- 

Thanks,

Matt