Open Stack

I wanted to highlight this email the Dims sent to the Foundation mailing list. I know many of your companies have expressed interest in longer support terms and this is the opportunity to get involved and help make that a reality.

If you want to join efforts around it, I’d suggest either reaching out on the Foundation mailing list or to Dims directly. I’m also happy to answer any questions. Thanks!

Jonathan


> Begin forwarded message:
> 
> From: Davanum Srinivas <davanum at gmail.com>
> Subject: [OpenStack Foundation] Upstream Long Term Support Releases (was Fwd: [openstack-dev] Developer Mailing List Digest November 11-17)
> Date: November 17, 2017 at 8:31:17 AM CST
> To: foundation at lists.openstack.org
> 
> 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-proposal
> 
> So 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 at gmail.com>
> Date: Fri, Nov 17, 2017 at 5:16 AM
> Subject: [openstack-dev] Developer Mailing List Digest November 11-17
> To: openstack-dev at lists.openstack.org
> Cc: openstack-operators at lists.openstack.org, user-committee at 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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> Davanum Srinivas :: https://twitter.com/dims
> _______________________________________________
> Foundation mailing list
> Foundation at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation-board/attachments/20171204/7d47c05d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mail Attachment
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/foundation-board/attachments/20171204/7d47c05d/attachment.sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation-board/attachments/20171204/7d47c05d/attachment-0001.html>