摘要

• POST /api-sig/news [0]
• R-14版本倒计时，11月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

上游长期支持版本

悉尼峰会就如何维护过去版本以提供长期支持（LTS）进行了一次非常成功的会议 [0]。

过去，社区曾要求对旧分支的维护感兴趣的人加入稳定维护团队，前提是如果稳定团队壮大，它可以支持更多分支更长时间。 这种做法已经重复了大约几年，但效果不佳。

本次讨论的重点是允许在生命周期结束后（EOL）继续进行补丁协作，并让那些愿意维护更长生命周期分支的人提出一套实际满足他们需求的测试，这些测试不太可能因不断变化的操作系统/PYPI基础而损坏。我们需要降低对我们可能产生的成果的期望，因为分支越旧，它就越容易变得脆弱。承担更多工作所带来的任何负担都由从事这项工作的人承担，不会对那些不感兴趣的人造成不当影响。

想法是继续当前的稳定策略，或多或少保持不变。开发团队负责几个稳定分支。 在某个时候，我们现在称之为EOL的分支，与其删除它，不如将其保留开放，并建立一个新的团队来继续维护该分支。 预计这些新团队的成员主要来自用户和分销商。 并非所有分支都会吸引团队进行维护，这没关系。

我们将停止标记这些分支，以便理解它们提供的支持级别。 可以共享补丁和其他修复，但要使用它们，用户必须构建自己的软件包。

测试作业将按原样运行，维护分支的团队可以决定如何处理它们。 尽可能地在上游修复作业是首选，但根据维护分支的人员、他们实际提供的支持级别以及错误的性质，删除单个测试或整个作业是另一种选择。 使用第三方测试被提出，但不是必需的。

正在一个etherpad [2] 中讨论为新组建的团队制定维护这些旧分支的策略。

房间里的一些反馈表示，他们希望每年启动一个版本，该版本的分支在一年后不会被删除。每年发布一个版本，并仍然保留 N-2 稳定版本。 我们仍然向所有开放的稳定分支进行回溯移植。 基本上，我们现在所做的事情，但每年一次。

关于此建议的讨论扩展到 OpenStack SIG 邮件列表 [1]，建议跳跃版本升级是处理升级痛苦的更好方法，而不是延长周期。 每六个月发布一次，改为每年发布一次，意味着我们的版本将包含更多更改，升级可能会变得更加痛苦。 我们应该尽可能频繁地发布，并使升级不那么痛苦，以便可以跳过版本。

到目前为止，我们一直能够找到人来维护稳定分支 12-18 个月。 将每年发布的 N-2 分支保留开放意味着将支持期延长至 2 年以上。 如果我们要这样做，我们需要解决如何留住贡献者的问题。

如果你发布得不够频繁，获得补丁“进入”的压力就会增加。 错过机会并等待一年是无法忍受的。

[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