Dear Board,
In the last OpenStack Board meeting, LTS was one of the "big" needs
that was brought up for the health of OpenStack going forward. Please
see the summary below and the etherpad of discussion/proposal at
https://etherpad.openstack.org/p/LTS-proposalSo far folks from RedHat have added their name (at the bottom of the
etherpad) for getting an effort off the ground.
I am looking for more folks from the Board, our Platinum and Gold
sponsors to help evangelize this inside their own organizations and
help us move this forward.
Looking forward to hearing from you all.
Thanks,
Dims
---------- Forwarded message ----------
From: Mike Perez <thingee@gmail.com>
Date: Fri, Nov 17, 2017 at 5:16 AM
Subject: [openstack-dev] Developer Mailing List Digest November 11-17
To: openstack-dev@lists.openstack.org
Cc: openstack-operators@lists.openstack.org, user-committee@lists.openstack.org
Contribute to the Dev Digest by summarizing OpenStack Dev List thread:
* https://etherpad.openstack.org/p/devdigest
* http://lists.openstack.org/pipermail/openstack-dev/
HTML version: https://www.openstack.org/blog/2017/11/developer-mailing-list-digest-november-11-17
Summaries
=========
* POST /api-sig/news [0]
* Release countdown for week R-14, November 18-24 [1]
[0] - http://lists.openstack.org/pipermail/openstack-dev/2017-November/124633.html
[1] - http://lists.openstack.org/pipermail/openstack-dev/2017-November/124631.html
Upstream Long Term Support Releases
===================================
The Sydney Summit had a very well attended and productive session [0] about to
go about keeping a selection of past releases available and maintained for long
term support (LTS).
In the past the community has asked for people who are interested in old
branches being maintained for a long time to join the Stable Maintenance team
with the premise that if the stable team grew, it could support more branches
for longer periods. This has been repeated for about years and is not working.
This discussion is about allowing collaboration on patches beyond end of life
(EOL) and enable whoever steps up to maintain longer lived branches to come up
with a set of tests that actually match their needs with tests that would be
less likely to bitrot due to changing OS/PYPI substrate. We need to lower
expectations of what we're likely to produce will get more brittle the older
the branch gets. Any burden created by taking on more work is absorbed by
people doing the work, as does not unduly impact the folks not interested in
doing the work.
The idea is to continue the current stable policy more or less as it is.
Development teams take responsibility of a couple of stable branches. At some
point what we now call an EOL branch, instead of deleting it we would leave it
open and establish a new team of people who want to continue to main that
branch. It's anticipated the members of those new teams are coming mostly from
users and distributors. Not all branches are going to attract teams to maintain
them, and that's OK.
We will stop tagging these branches so the level of support they provide are
understood. Backports and other fixes can be shared, but to consume them, a
user will have to build their own packages.
Test jobs will run as they are, and the team that maintain the branch could
decide how to deal with them. Fixing the jobs upstream where possible is
preferred, but depending on who is maintaining the branch, the level of support
they are actually providing and the nature of the breakage, removing individual
tests or whole jobs is another option. Using third-party testing came up but is
not required.
Policies for the new team being formed to maintain these older branches is
being discussed in an etherpad [2].
Some feedback in the room expressed they to start one release a year who's
branch isn't deleted after a year. Do one release a year and still keep N-2
stable releases around. We still do backports to all open stable branches.
Basically do what we're doing now, but once a year.
Discussion on this suggestion extended to the OpenStack SIG mailing list [1]
suggesting that skip-release upgrades are a much better way to deal with
upgrade pain than extending cycles. Releasing every year instead of a 6 months
means our releases will contain more changes, and the upgrade could become more
painful. We should be release often as we can and makes the upgrades less
painful so versions can be skipped.
We have so far been able to find people to maintain stable branches for 12-18
months. Keep N-2 branches for annual releases open would mean extending that
support period to 2+ years. If we're going to do that, we need to address how
we are going to retain contributors.
When you don't release often enough, the pressure to get a patch "in"
increases. Missing the boat and waiting for another year is not bearable.
[0] - https://etherpad.openstack.org/p/SYD-forum-upstream-lts-releases
[1] - http://lists.openstack.org/pipermail/openstack-sigs/2017-November/000149.html
[2] - https://etherpad.openstack.org/p/LTS-proposal
--
Mike Perez (thingee)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Davanum Srinivas :: https://twitter.com/dims