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