OpenStack 开发人员邮件列表摘要 11月7日-13日
- 对于发布管理，我们结合使用 launchpad 里程碑页面和我们的 wiki 来跟踪发布中的变更。
- 我们过去是在发布时提取稳定点发布的发布说明。
- 发布经理会在每个里程碑与 PTL 和发布联络人合作，更新 launchpad 以反映已完成的工作。
- 这需要稳定维护和发布团队付出大量工作。
- 为了解决随着项目不断增多的工作量，发布团队正在引入 Reno，以便持续构建树中的发布说明文件。
- 其想法是小的 YAML 文件，通常每个说明或补丁一个，以避免回端口上的合并冲突，然后将其编译成可读文档供读者阅读。
- 支持使用 ReStructuredText 和 Sphinx 将说明文件转换为 HTML 以供发布。
- 有关使用 Reno 的文档可在 [1] 处找到。
- 发布联络人应在现在到 Mitaka-1 里程碑之间为每个项目创建并合并几个补丁
- 到主分支，发布说明的发布说明。Glance 的一个例子 [2]。
- 项目稳定/liberty 中发布说明。Glance 的一个例子 [3]。
- project-config 中的相关任务。Glance 的一个例子 [4]。
- Reno 在峰会之前还没有准备好，因此 wiki 被用于 Liberty 初始版本的发布说明。联络人应将这些说明转换为 stable/liberty 分支中的 Reno YAML 文件。
- 使用主题“add-reno”来跟踪所有补丁的采用情况。
- 一旦联络人完成这项工作，就可以停止使用 launchpad 来跟踪已完成的工作。
- 现在，launchpad 仍然用于跟踪错误报告。
- Tony Breeds 正在征求关于让 Juno 保持活跃更长时间的反馈。
- 根据当前的用户调查 [5]，Icehouse 仍然在生产云中拥有最大的安装基础。Juno 位居第二，这意味着如果我们本月结束 Juno 的生命周期 (EOL)，那么大约 75% 的生产云将运行 EOL 版本的软件。
- 然而，这样做存在问题
- 运行确保稳定分支仍然可用的必要任务的 CI 容量。
- 缺乏关心稳定分支继续工作的资源。
- Juno 仍然与 Python 2.6 绑定。
- 仍然需要安全支持。
- Tempest 是无分支的，因此它正在运行稳定的兼容任务。
- 这被认为是常见的请求。常见的答案是“投入更多资源来修复现有的稳定分支，我们可能会考虑一下”。
- Matt Riedmann 在稳定分支的战壕中工作，证实 stable/juno 已经因为需求上限问题而宣告报废。你修复一个问题来解除一个项目的阻塞，然后由于全局需求同步，我们又破坏了另外两个项目。这个循环永无止境。
- 由于我们在全局需求中更好地隔离了版本和上限常量，因此 stable/kilo 不存在相同的问题。
- Sean Dague 想知道是什么原因阻止人们开始升级。Tony 无法给出原因，因为其中一些原因是他公司提供的内部原因。
- Davanum 注意到一个补丁来删除 py26 oslo 任务 [6]。
- Jeremy Stanley 提到基础设施团队计划删除 CentOS 6.X 任务工作者，其中包括所有 python 2.6 任务，当 stable/juno 到达 EOL 时。
- Thierry 写道，当发布周期管理团队成立时，它碰巧包含了发布管理、稳定分支管理和漏洞管理。
- 提案：也将稳定分支维护分离出去。
- 稳定团队的大部分工作过去是稳定点发布管理，但从 stable/liberty 开始，现在由发布管理团队完成，并由特定项目的稳定维护团队触发，因此在那里不再有工具重叠。
- 稳定团队现在专注于稳定分支策略 [7]，而不是补丁。
- Doug Hellmann 领导发布团队，并且没有 Thierry 对稳定分支策略的历史。
- 赋予团队自主决策权、可见性和认可，希望鼓励更多资源投入其中。
- 定义和执行稳定分支策略。
- 如果团队扩大，它可以拥有稳定分支健康/修复门控。然后，该团队可以决定支持时间框架。
- Matthew Treinis 不同意团队分离能够解决获得更多人来处理门控问题的方案。Thierry 确实有证据表明将其打造成为一个独立的项目将带来额外的资源。另一种选择是杀死稳定分支，但正如我们从“让 Juno 保持活跃”主题中看到的，人们仍然有兴趣拥有它们。
发表评论