PTL 指南¶
作为 Oslo PTL，有一些 Oslo 特有的方面需要注意。本文档旨在记录这些内容，供未来参考。
问题描述¶
每个 PTL 在任职期间都会学习到一些关于这个职位的信息。然而，历史上他们一直保存着私人的笔记，这些笔记需要从一个 PTL 传递到另一个 PTL，这并不是理想的。首先，如果由于任何原因未能完成交接，新的 PTL 将不得不从头开始。其次，这使得这些笔记对公众隐藏，这对潜在的未来 PTL 候选人没有用。
拟议政策¶
这应该是一个持续更新的文档，由 PTL 在发现新的最佳实践和领导 Oslo 项目的技巧时进行更新。
新的或未来的 PTL 应该首先阅读 项目团队指南 PTL 文档。它包含大量 PTL 应该了解的有用信息。特别注意关于授权的部分。
发布¶
通常，PTL 或发布联络人应每周为所有需要发布的 Oslo 库 提出发布请求。通常这在每周的早期进行，并且尽可能避免在周五发布，以避免任何人需要在周末修复故障。如果需要立即发布关键修复，则无需等待常规每周发布周期。每周周期的目的是确保及时发布更改，而不是阻止任何内容的发布。
PTL 可以酌情对每周发布计划进行例外。在大多数团队成员不在的假期前发布不是理想的。在新的稳定分支被切分后，最好等待与稳定分支相关的发布发布，然后再发布 master。这样可以回溯依赖项的更新，以防在 OpenStack 发布的最终测试期间发现错误。在这种情况下，需要进行次要版本更新，如果 master 已经发布，那么该次要版本已经被占用。
注意
通常，不允许在稳定分支上进行次要版本更改，但如果情况需要，可以例外。有关更多详细信息，请参阅 稳定分支指南。
在进行发布时，有一些有用的命令要知道。首先，要查找自上次发布以来所有 Oslo 库中的所有更改，请在 openstack/releases 仓库中使用以下命令
./tools/list_unreleased_changes.sh master $(.tox/venv/bin/list-deliverables --team oslo -r)
./tools/list_unreleased_changes.sh master $(.tox/venv/bin/list-deliverables --team oslo -r --series independent)
注意
这些命令假定已创建 venv tox 环境。可以使用命令 tox -e venv --notest 来完成。
注意
Oslo 包含与 OpenStack 发布版本相关联的库，以及一些与其无关的库。这就是为什么需要两个命令来涵盖所有库的原因。
要对稳定分支执行相同的操作，请使用以下命令（根据需要替换分支名称）
./tools/list_unreleased_changes.sh stable/train $(.tox/venv/bin/list-deliverables --team oslo -r --series train)
会议¶
Oslo 团队通常每周开会一次。具体的日期和时间可以在 eavesdrop 页面 上找到。PTL 通常主持会议，但其他贡献者也可以在需要或希望的情况下主持会议。会议议程可以在 wiki 页面 上找到。主持会议包括浏览议程中的主题 - 有些周这需要 15 分钟或更短的时间，而另一些周则需要整整一个小时或更长时间。
Ping 列表¶
Oslo 团队在 会议议程模板 中使用礼貌的 ping 列表，以便提醒定期参加会议的人员会议开始时间。与会者可以根据需要添加或删除他们的姓名，每周运行会议的人员应将 ping 列表复制到 IRC，以便列表中的每个人都收到通知。
每周 Wayward 审查¶
这个会议主题需要更多的解释。想法是找到一个旧的审查并以某种方式推进它。这意味着在会议结束时，审查应该被批准、-1’d，或者有人被指定在会议后跟进。
bnemec 使用 reviewstats 查找 Oslo 中最旧的未完成审查。
周期开始活动¶
应清除每个周期的 ping 列表，以避免 ping 不再参与 Oslo 工作的人员。可以并行创建一个新的 ping 列表，以便希望保留在列表中的贡献者可以在清除列表之前注册。这两个并行列表应存在几周，以便每个人都有机会更新新的列表。
当宣布新的发布名称时，需要将其添加到 oslo.log versionutils 模块中。请参阅此 versionutils 审查 以获取示例。
在每个周期的开始，Oslo 功能冻结 日期应添加到发布日历中。请参阅此 功能冻结日期审查 以获取执行此操作的示例。可以在 功能冻结 策略中找到 Oslo 拥有自己功能冻结的详细解释。
检查 oslo-coresec 组，并确保所有成员都是活跃的 Oslo 核心成员，以便私有安全漏洞不会发送给不需要看到它们的人。如有必要，添加当前核心团队成员以确保核心安全团队有足够的人员来处理任何传入的安全漏洞。
有关管理核心安全团队的更多详细信息，请参阅 漏洞管理团队的要求。
周期结束活动¶
确保所有库在非客户端库冻结之前发布，即使它们没有通常会提示发布的更改（例如文档或测试更改）。现在这可能由发布团队自动处理，但仍然明确地执行它仍然很好。在切分稳定分支之前发布所有更改非常重要，因为分支是基于上次发布的提交，而不是 master 上当时的内容。如果存在未发布的文档或测试更改，它们可能会在稳定分支上丢失，并且需要回溯。
在完成库的最终发布时，还要请求创建相应的稳定分支。有关如何执行此操作的示例，请参阅 此分支创建请求。将来，所有这些都可以在一个审查中完成，但这是以前流程的更改，因此目前还没有示例审查。
在进行最终发布时，可以通过将
--stable-branch添加到 new_release.sh 调用中，轻松地包含分支创建。例如./tools/new_release.sh ussuri oslo.config feature --stable-branch
PTL 交接活动¶
希望这些活动大部分都是自动化的，但有一件事需要手动完成，那就是使新的 PTL 成为 Launchpad 中 oslo-coresec 组的管理员。
替代方案与历史¶
如问题描述中所讨论的，我们可以继续让 Oslo PTL 维护一组私有笔记，这些笔记单独传递给下一个 PTL。由于前面提到的原因，这并不是首选的。
实现¶
里程碑¶
N/A
工作项¶
编写策略本身是主要工作项目。随着社区的发展，更新它将是一个持续的过程。
参考资料¶
修订历史¶
发布名称 |
描述 |
|---|---|
Ussuri |
引入 |
注意
本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode
