稳定分支

稳定分支旨在为自某个发布版本以来，在主分支上修复的高影响错误和安全问题提供一个安全的修复来源。

稳定分支是在 6 个月常见的开发周期结束时，从给定交付版本的最后一个发布版本中切分出来的。

维护阶段

项目稳定分支将处于以下状态之一

状态	时间范围	摘要
维护中	大约 18 个月	所有错误修复（符合以下描述的标准）都是合适的。发布版本生成。
未维护	只要社区对此感兴趣。	仅 SLURP 发布版本。所有错误修复（符合以下描述的标准）都是合适的。不生成发布版本，降低 CI 承诺。
生命周期结束 (EOL)	不适用	分支不再接受更改。

并非要求给定分支的所有项目在同一时间过渡到不同的阶段。例如，openstack/long-life-project 的 stable/$series 分支仍然处于维护中阶段，而所有其他项目已经过渡到 未维护 甚至 生命周期结束 也是完全合理的。

注意

如何确定分支的状态？

当前开发分支

这是仓库中的 master 分支。

项目的核心团队（例如，cinder-core）负责将更改合并到此分支。

维护中的分支

这些是仓库中的 stable/$series 分支，例如，stable/2023.1。

项目的稳定核心团队（例如，cinder-stable-maint），可能是核心团队的一个子集，负责将更改合并到维护中的分支。

项目的 PTL 或发布团队联络人必须确认维护分支提出的发布版本，然后由 OpenStack 发布管理团队批准。

有关详细信息，请参阅 稳定维护团队。

未维护分支

这些是仓库中的 unmaintained/$series 分支，例如，unmaintained/xena。

有一个全局的 openstack-unmaintained-core 团队负责将更改合并到未维护分支。可选地，单个项目可以有一个 $project-unmaintained-core 团队（例如，ironic-unmaintained-core），该团队负责此项工作，并且可以覆盖全局团队对未维护分支的批准权。

不允许从未维护分支发布版本。

对未维护分支的更改预计是 合适的修复，如本文档的其他地方所述。

生命周期结束

这些在代码仓库中不存在作为分支，但可以通过检出 $series-eol 标签来重新创建，例如，train-eol。

维护中

对于被认为是维护中的任何项目/分支组合，OpenStack 基础设施、OpenStack 漏洞管理 和 QE 工具预计可以正常工作并处于活动状态。项目团队将生成可消耗的发布版本，并且将测试升级。

在此阶段，每个项目稳定团队和稳定维护者负责所有声明遵循稳定分支策略的项目。

未维护

注意

只有 SLURP 分支才有资格获得未维护状态。

在分支不再处于维护中状态后，该分支将被标记为 $series-eom，stable/$series 分支将被删除，并基于 $series-eom 标签创建一个 unmaintained/$series 分支。

不允许从未维护分支发布版本。

默认情况下，仅保留最新的符合条件的未维护分支。为了防止未维护分支在较新的符合条件的进入状态后自动过渡到 生命周期结束，未维护分支联络人必须手动选择加入，如下面所述。

注意

PTL 或未维护分支联络人可以指定，但不应期望上游社区团队保持分支开放。对给定分支感兴趣的社区成员鼓励在分支生命周期的早期与适当的项目团队联系，以确保此过程顺利进行。如果没有识别出维护者，该分支将自动过渡到 生命周期结束。

要选择加入以保持未维护分支开放，PTL 或未维护分支联络人必须对 openstack/releases 仓库中的相应补丁进行 -1 操作，以结束该分支的生命周期。请联系 PTL 或未维护分支联络人以表示有兴趣帮助保持分支开放，进行回溯和审查。该补丁在提出后至少一个月才能合并。即使 PTL 或联络人已投票 +1 以结束分支的生命周期，该补丁仍必须保持开放整个宽限期，以便允许其他社区成员有机会志愿接管。

要符合选择加入的资格，分支必须具有功能性 CI，包括已发布支持的 Python 版本的单元测试。功能性 CI 意味着所有配置的测试都通过并且不会在 Zuul 中生成错误。

此外，在最旧的未维护分支和当前维护版本之间不得跳过任何 SLURP 分支。这确保了操作员有一个从一个 SLURP 升级到下一个 SLURP，最终升级到维护版本的升级路径。

注意

有关未维护状态的更多详细信息，请参阅 OpenStack 技术委员会的决议 未维护状态取代扩展维护，并对其进行修改以定义 openstack-unmaintained-core Gerrit 组。

警告

Tempest 及其插件是无分支的，并且不能保证 Tempest 的主版本或其插件将继续支持未维护分支。

注意

有关更多信息，请参阅 Tempest 稳定分支支持策略。

如果 Tempest 主分支在测试未维护分支时开始出现故障，那么我们需要使用 Tempest 及其插件兼容版本策略 中的最新兼容版本。

为了使 Tempest 及其插件的最新兼容版本可用于特定分支，在分支进入未维护状态时，Tempest 维护者将在主分支哈希值处发布一个新标签，名称为 $series-last（以及一个新的版本号）。tempest 插件的维护者也将为每个插件发布 $series-last 标签。

这使得希望继续对未维护分支（上游或在生产云中）进行 CI 测试的 Tempest 用户可以轻松识别该分支的 Tempest 及其插件的最新兼容版本。它比要求任何希望在未维护分支上使用 Tempest 的人手动尝试找到可用的版本更可靠。

有关创建 Tempest 和其插件的 $series-last 标签的示例，请查看这些 Gerrit 审查：https://review.opendev.org/q/topic:%22tempest-plugin-stein-last%22+(status:open%20OR%20status:merged

生命周期结束

如果分支无资格作为未维护分支保持活动状态，或者团队决定明确结束对分支的支持，它将变为生命周期结束。适当分支的 HEAD 将被标记为 $series-eol 并删除该分支。

要启动此过渡，给定项目的 PTL 或其他稳定维护者应

1. 向 openstack-discuss 邮件列表发送公告（以便给其他人一些时间来作为维护者站出来，如果有志愿者）。

2. 删除在 other repositories 中定义的任何相关 zuul 作业，并且不再需要。

3. 针对给定的项目/仓库提出补丁。（例如，请参阅：https://review.opendev.org/#/c/677478/）

4. 在分支被标记为 $series-eol 后，请求发布管理团队删除该分支。

合适的修复

只有有限的更改类别适合包含在稳定分支中。在考虑更改时，必须权衡许多因素

1. 回归风险：即使是最小的更改也存在破坏某些东西的风险，我们真的想避免稳定分支上的回归

2. 用户可见的好处：我们是否修复了用户可能实际注意到的东西，如果是，它有多重要？

3. 修复的自包含性：如果它修复了一个重要问题，但也重构了大量代码，那么可能值得考虑一个风险较低的修复方案

4. 如果修复已经存在于主分支和所有后续的稳定分支中：更改必须是已经合并到主分支上的更改的回溯，除非更改在主分支上没有意义。同样适用于 N-2 版本，其中 N 是主分支，在这种情况下，N-1 和 N 分支都应该合并补丁，依此类推。

注意

尽管如此，如果可以轻松证明其安全性，也可以回溯其他错误的修复。例如，文档修复、调试日志消息拼写更正、仅测试更改、增强测试覆盖率的补丁、配置文件内容修复可以应用于所有受支持的分支。对于这些类型的回溯，稳定维护者将根据具体情况决定。

注意

某些补丁可能会从规则 4 中获得例外。这些补丁不触及生产代码，例如仅测试补丁，或修复主要门控中断的 tox.ini 更改等；或者安全补丁在发布补丁后不应花费太多时间进行合并。在这些情况下，稳定补丁可以在没有等待所有后续分支修复的情况下推送到门控。

警告

如果审查过程发现稳定补丁合并后主补丁中的问题需要重新工作，预计将进行额外的更改合并到稳定分支，以避免分支之间的不必要的差异。因此，谨慎使用例外情况。

任何人都可以提出稳定分支回溯。有关如何操作的更多信息，请参阅 提出修复。

稳定维护团队

每个项目团队应指定一个 稳定分支跨项目联络人 作为团队中所有稳定分支支持问题的主要联系人。如果未指定任何人，则假定 PTL 将承担该职责。

项目特定团队

每个具有稳定分支的项目都将有一个项目特定的稳定维护 Gerrit 团队，名为 PROJECTNAME-stable-maint。该团队将具有 CodeReview+2 和 Workflow+1 权限，可以对稳定分支进行操作，并负责根据稳定分支策略的规则审查给定项目的回溯。该组应是项目稳定分支核心（不一定为主核心）+ 稳定维护核心团队。该组由项目团队像管理其主分支核心团队一样进行管理。要管理该组或稳定策略，他们可以咨询稳定维护核心团队。

稳定维护核心团队

稳定维护核心团队 负责稳定分支策略的定义和执行。它将为项目特定的稳定维护组提出的所有可疑回溯提供例外情况，在各处提供回溯审查帮助，维护稳定分支策略（并确保其规则得到遵守），教育拟议的项目特定团队成员这些规则，并将他们添加到这些项目特定团队。

主动维护

项目特定的团队预计将主动维护其稳定分支，通常包括

1. 遵循 审查指南。特别是，不允许回溯新功能、新依赖项或不向后兼容的更改。

   • 提示：如果项目版本在稳定/liberty 或更高版本的稳定分支全局要求中有一个上限，这意味着有一个破坏该稳定分支的不向后兼容的更改。这通常适用于库和客户端项目。

2. 主动识别并从主分支回溯重要的错误修复。这意味着团队正在尝试在任何人遇到问题并不得不报告错误或提出回溯之前，在稳定分支上解决回归和其他高影响问题（在他们的生产云中）。没有关于应该回溯多少从主分支发现并修复的错误或回溯到稳定分支的规则。主要思想是在所有适当的分支上快速解决回归和其他高影响问题。

3. 监控开放的 backport 评审积压情况，并及时实际评审它们。

4. 发布频率要足够高，以便发布修复程序，同时又不使发布团队或用户不堪重负。通常，安全修复和其他关键错误修复应快速发布。否则，当有合理的未发布修复程序提交时，团队应考虑进行发布。在主版本发布计划期间的里程碑边界也是检查未发布更改列表以查看是否应发生稳定的点发布的良好时机。

5. 监控和解决连续集成“门”系统中的问题。基本上，这意味着确保没有阻止建议的 backport 通过测试的事情。这些可能是项目特定的或全局性的，通常在 stable tracker etherpad 中跟踪。不时地，稳定维护核心团队也可能会在 IRC 或 openstack-discuss 邮件列表中向各个项目寻求帮助，并期望得到及时响应。

   注意

   声称遵循稳定分支策略的项目应在其项目的 Zuul 配置文件中运行 periodic-stable-jobs 模板，通常是 .zuul.yaml (示例 .zuul.yaml) 或 zuul.d/project.yaml (示例 zuul.d/project.yaml)。

   该模板在 zuul.d/project-templates.yaml 中定义，位于 openstack/openstack-zuul-jobs 仓库 中，并由 OpenStack QA 团队维护。

6. 稳定的分支跨项目联络员应在 OFTC IRC 的 #openstack-stable 频道中提供，以回答问题或了解问题。

未维护分支维护

未维护分支不是各个项目团队的责任（当然，这并不禁止各个项目团队成员在未维护分支上工作）。

相反，有一个全局的 openstack-unmaintained-core 团队，该团队拥有维护未维护分支上运行的 CI 的权限，以及将适当的更改合并到未维护分支的权限。

此外，每个项目可能拥有（但不要求拥有）一个名为 PROJECTNAME-unmaintained-core 的 Gerrit 团队来处理该项目未维护分支上的所有工作。该组由 PTL 或未维护分支联络员（如果有）管理。该组是通过在 openstack/project-config 仓库中的项目 Gerrit ACL 中提出适当的权限集来创建的。请参阅 https://review.opendev.org/c/openstack/project-config/+/902796 以获取示例。

注意

要成为 openstack-unmaintained-core 团队的成员，首先必须了解稳定策略，因为它仍然适用于未维护分支。然后联系该团队本身，并表明有兴趣成为该团队的成员以及维护项目（或多个项目）及其 CI 的意图，然后该团队将决定并授予成员资格。

评审指南

每个项目稳定评审团队需要平衡任何给定补丁的风险与其为稳定分支用户提供的价值。对于主要的严重数据损坏问题，一个大型且有风险的补丁可能是有意义的。对于相当晦涩的错误处理情况的微小修复也是如此。

某些类型的更改完全禁止

• 新功能

• 外部 HTTP API 的更改

• Nova 内部 AMQP API 的更改

• 通知定义更改

• 数据库模式更改

• 不兼容的配置文件更改

提出的 backport 违反上述任何指南，可以在 openstack-discuss 列表中讨论为例外请求（前缀为 [stable]），稳定维护核心团队将拥有最终决定权。

每个建议提交到 Gerrit 的 backport 应该由两个项目特定的稳定维护团队成员进行评审并 +2 批准后才能获得批准。如果团队成员已经 backport 了修复程序，则其他一个 +2 就足以获得批准。

如果不确定给定修复程序的具体技术细节，项目特定的稳定维护团队成员应咨询适当的项目核心评审人员进行更详细的技术评审。

如果不确定修复程序是否适合稳定分支，项目特定的稳定维护团队成员应征求稳定维护核心团队成员的意见。

强烈鼓励现有的核心评审人员加入稳定维护团队，以帮助评审 backport，判断其对稳定分支的适用性并批准它们。

针对禁运的安全问题的修复程序会受到特殊对待。有关更多信息，请参阅漏洞管理章节。

流程

OpenStack 开发通常同时存在 3 个分支处于活动状态，master（当前开发版本）、stable（最新版本）和 oldstable（先前版本）。有时可能存在较旧的分支，但对此的讨论超出了本指南的范围。

为了接受一个更改到 $release，它必须首先被接受到所有分支，一直到 master。

为了便于讨论，假设一个假设的开发里程碑

• 开发分支 (master) 将是 Uniform 版本。

• N-1 分支是 stable/tango

• N-2 分支是 stable/sierra

• N-3 分支是 stable/romeo

• 依此类推

Backport 示例

• Tango 的更改必须存在于 master 中

• Sierra 的更改必须存在于 stable/tango 和 master 中

• Romeo 的更改必须存在于 stable/sierra、stable/tango 和 master 中

• 依此类推

提出修复程序

任何人都可以向 stable-maint 团队提出 cherry-pick。

一种方法是，如果 launchpad 中的错误看起来是 backport 的一个好候选者 - 例如，如果它是先前版本中的一个重要错误 - 那么只需将该错误提名到稳定系列（stable 或 oldstable）就会引起维护者的注意，例如 Nova Kilo 提名

如果您没有适当的权限来提名该错误，那么使用例如 $release-backport-potential 标记它也足够了，例如 Nova Liberty potential

以最及时的方式获得补丁合并的最佳方法是自己 backport 它。为此，您可以尝试使用 Gerrit UI 中 master 中原始补丁的“Cherry Pick To”按钮。Gerrit 将负责创建一个新的评审，修改提交消息以包含“cherry-picked from …”行等。

注意

backport 必须与 master 提交匹配，除非有严重的需求不同，例如 gate 失败、测试框架在 master 中已更改、代码重构或其他原因。如果您收到建议增强您的 backport 的建议，而这与此意图相反，则应将评审人员转介到 上面的警告。

您可以使用 git-review 将更改建议到假设的稳定分支，如下所示

$ git checkout -t origin/stable/tango
$ git cherry-pick -x $master_commit_id
$ git review stable/tango

注意

cherry-pick -x 选项在提交消息中包含“cherry-picked from …”行，这对于避免 Gerrit 错误 是必需的

如果所有这些都失败了，只需 ping 团队中的一个成员并提及您认为该错误/提交是 backport 的一个好候选人即可。

冲突

如果您提出的补丁无法干净地 cherry-pick，您可以帮助通过自行解决冲突并提出结果补丁。请在提交消息中保留“Conflicts”行以帮助评审人员，例如：https://review.opendev.org/686292/

注意

如果 cherry-picked 补丁的提交消息包含不再在目标分支中有效的“Conflicts”行，则删除这些行。

Change-Ids

在 cherry-pick 提交时，保留原始 Change-Id，Gerrit 将显示稳定分支的单独评审，同时仍然允许您使用 Change-Id 查看所有关联的评审。请参阅此更改作为示例。

警告

Change-Id 行必须在最后一段中。backport 中的冲突会添加新段落，从而创建一个新的 Change-Id，但您可以通过将冲突移动到带有 Change-Id 行的段落之上或删除空行以创建一个段落来避免这种情况。

发布

对于稳定发布，分支应以与 backport 修复程序相同的顺序发布。例如，要发布分支 N-1，我们应该首先发布分支 N 并继续以相同的顺序发布 N、N-1、N-2 等。

不需要一起发布所有稳定分支，但为了避免冲突，我们应该只发布分支 N-1，其中包含已经发布在分支 N 发布中的更改，并应避免出现较旧分支发布包含不存在于较新分支发布中的修复程序的情况。对此情况可能存在例外，但这是发布稳定分支的首选方式。

电子邮件通知

如果您想收到有关新的稳定补丁的通知，您可以在 gerrit 监视的项目 屏幕上使用以下设置创建监视。

Project Name: All-Projects
     Only If: branch:stable/liberty

然后选中“电子邮件通知 - 新更改”复选框。这将导致 gerrit 在提出匹配的更改时发送电子邮件，并且更好的是，该更改将显示在 gerrit 的“监视的更改”列表中。

请参阅有关 gerrit notify 配置和 gerrit 搜索 语法的文档。

错误标签

带有 $release-backport-potential 标记的错误是适用于稳定版本并且在修复后可能适合 backport 的错误。一旦提出了 backport，就应删除该标签。

Gerrit 会在将错误合并到稳定分支时使用 in-stable-$release 标记错误。发布管理器稍后会在错误针对适当的系列时删除该标记。

门状态

保持稳定分支的良好状态是一项持续的努力。要查看当前导致 gate 失败并阻止代码合并到稳定分支的错误，请参阅 stable tracker etherpad，我们将在其中跟踪当前错误和正在进行的修复程序。

每天都会为每个项目稳定分支进行计划的测试运行。如果出现故障，该机器人将向 openstack-stable-maint 邮件列表 发送电子邮件。最好快速响应这些并尽快解决它们，以防止它们堆积起来。如果您有兴趣提供帮助，请订阅。

声称遵循稳定分支策略的项目团队

如果他们的稳定分支策略发生任何变化（项目停止或开始遵循稳定分支策略），则可以更新此列表。

1. Barbican（密钥管理器服务）：barbican

2. Cinder（块存储服务）：cinder、cinderlib、os-brick、python-brick-cinderclient-ext、python-cinderclient

3. Designate（DNS 服务）：designate、designate-dashboard、python-designateclient

4. Glance（镜像服务）：glance、glance-store、python-glanceclient

5. Heat（编排服务）：heat、python-heatclient

6. Horizon（仪表板）：horizon

7. Ironic（裸机服务）：ironic、ironic-inspector、ironic-lib、ironic-python-agent、python-ironic-inspector-client、python-ironicclient

8. Keystone（身份服务）：keystone、keystoneauth、keystonemiddleware、pycadf、python-keystoneclient

9. Manila（共享文件系统服务）：manila

10. Neutron（网络服务）：neutron-fwaas、neutron、neutron-dynamic-routing、neutron-lib、neutron-vpnaas

11. Nova（计算服务）：nova、python-novaclient

12. Octavia（负载均衡器服务）：octavia、octavia-dashboard、python-octaviaclient、octavia-lib

13. Oslo（通用库）：automaton、castellan、oslo.cache、oslo.config、oslo.context、oslo.db、oslo.messaging、oslo.middleware、oslo.policy、oslo.privsep、oslo.serialization、oslo.service、oslo.upgradecheck、oslo.utils、oslo.versionedobjects、oslo.vmware、stevedore

14. Swift（对象存储服务）：python-swiftclient、swift

15. Zaqar（消息服务）：zaqar