Open Stack

On 11/10/2017 11:51 PM, John Dickinson wrote:
> On 7 Nov 2017, at 15:28, Erik McCormick wrote:
> 
>     Hello Ops folks,
> 
>     This morning at the Sydney Summit we had a very well attended and very
>     productive session about how to go about keeping a selection of past
>     releases available and maintained for a longer period of time (LTS).
> 
>     There was agreement in the room that this could be accomplished by
>     moving the responsibility for those releases from the Stable Branch
>     team down to those who are already creating and testing patches for
>     old releases: The distros, deployers, and operators.
> 
>     The concept, in general, is to create a new set of cores from these
>     groups, and use 3rd party CI to validate patches. There are lots of
>     details to be worked out yet, but our amazing UC (User Committee) will
>     be begin working out the details.
> 
>     Please take a look at the Etherpad from the session if you'd like to
>     see the details. More importantly, if you would like to contribute to
>     this effort, please add your name to the list starting on line 133.
> 
>     https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases
> 
>     Thanks to everyone who participated!
> 
>     Cheers,
>     Erik
> 
>     _______________________________________________
>     OpenStack-operators mailing list
>     OpenStack-operators at lists.openstack.org
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> I'm not a fan of the current proposal. I feel like the discussion jumped into a 
> policy/procedure solution without getting much more feedback from operators. The 
> room heard "ops want LTS" and we now have a new governance model to work out.
> 
> What I heard from ops in the room is that they want (to start) one release a 
> year who's branch isn't deleted after a year. What if that's exactly what we 
> did? I propose that OpenStack only do one release a year instead of two. We 
> still keep N-2 stable releases around. We still do backports to all open stable 
> branches. We still do all the things we're doing now, we just do it once a year 
> instead of twice.

The problem is around making breaking changes, e.g. removing configuration 
options. Currently we can do it, roughly speaking, up to 6 months after 
deprecation. Your suggestions bumps it to up to 12 months, if we want to support 
the same deprecation model.

> 
> Looking at current deliverables in the openstack releases repo, most (by nearly 
> a factor of 2x) are using "cycle-with-intermediary".
> 
> |john at europa:~/Documents/openstack_releases/deliverables/pike(master)$ grep 
> release-model * | cut -d ':' -f 2- | sort | uniq -c 44 release-model: 
> cycle-trailing 147 release-model: cycle-with-intermediary 37 release-model: 
> cycle-with-milestones 2 release-model: untagged |
> 
> Any deliverable that using this model is already successfully dealing with 
> skip-level upgrades. Skip-level upgrades are already identified as needed and 
> prioritized functionality in projects that don't yet support them. Let's keep 
> working on getting that functionality supported across all OpenStack 
> deliverables. Let's move to one LTS release a year. And let's get all project 
> deliverables to start using cycle-with-intermediary releases. >
> --John
> 
> 
> 
> __________________________________________________________________________
> 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
>