[openstack-dev] [Openstack-operators] Upstream LTS Releases
dtantsur at redhat.com
Mon Nov 13 09:09:33 UTC 2017
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.
> Thanks to everyone who participated!
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> 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. >
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev