SuccessBot 说

• redrobot: Barbican API 指南现在正在发布。 [1]
• jroll: ironic 5.1.0 版本发布，作为 stable/mitaka 的基础。
• ttx: 所有里程碑驱动型项目的 RC1 版本已上线。
• zara: storyboard.openstack.org 现在发送电子邮件了！
• noggin143: 我的第一个 bays 在 CERN 生产云中使用 Magnum 运行。
• sdague: Grenade 已升级至 testing stable/liberty -> stable/mitaka 和 stable/mitaka -> master。
• 通过 IRC 发送消息“#success [插入成功案例]”告诉我们你的成功案例。
• 全部

PTL 选举结果

• 结果出来了，祝贺大家！ [2]
• TC 为无领导项目任命 PTL [3]
  • EC-API: Alex Andrelevine
  • 稳定分支维护: Tony Breeds
  • Winstackers: Claudiu Belu
• 完整线程

技术委员会职位候选人提案现已开放

• 重要日期
  • 提名开始：2016-03-25 00:00 UTC
  • 提名结束：2016-03-31 23:59 UTC
  • 选举开始：2015-04-01 00:00 UTC
  • 选举结束：2015-04-07 23:59 UTC
• 关于选举的更多细节 [4]
• 完整线程

R-1 周发布倒计时，3 月 27 日 – 4 月 1 日

• 重点
  • 遵循里程碑周期模型的项目团队应测试他们的发布候选版本。
  • 遵循带有中间版本的周期模型的项目团队应至少有一个 Mitaka 版本，并确定在 Mitaka 周期结束前是否需要另一个版本。
  • 所有项目都应致力于修复发布关键错误。
• 常规说明
  • 全局需求列表仍然冻结。
  • 如果您需要更改依赖项以修复发布关键错误，请在变更请求中提供足够的详细信息。
  • 遵循里程碑周期模型的项目的 master 分支已开放用于 Newton 开发工作。
• 发布操作
  • 遵循带有中间版本的周期，但未明确表示将要发布最终版本的项目
    • bifrost
    • magnum
    • python-searchlightclient
    • senlin-dashboard
    • solum-infra-guestagent
    • os-win
    • cloudkitty
    • tacker
  • 这些项目应尽快联系发布团队或将发布请求提交到 releases 仓库。请最晚在周三或周四提交请求。
    • 3 月 31 日之后，功能发布将被计入 Newton 周期。
  • 发布团队在 R1 和峰会之间由于出行原因将减少可用性。使用开发邮件列表联系团队，并在主题中包含“[release]”。
• 完整线程

机器人及其影响：Gerrit、IRC、其他

• 机器人非常方便地执行重复性任务。
• 这些机器人需要权限才能执行某些操作，需要维护以确保它们按预期运行，并且会产生一些人认为是音乐，另一些人认为是噪音的输出
• 来自 infra 会议 [5]，到目前为止已经提出了以下问题
  • 权限：在 gerrit 上拥有 +2 +A 权限的机器人是我们希望避免的。
  • “未经授权”的机器人（不在 infra 配置文件中的机器人）在多个团队共享的频道中（会议频道、-dev 频道）
  • 形成对机器人的依赖，并期望 infra 追溯性地维护它们（示例：bot soren 直到 soren 不再维护）
  • 由于存在回显机器人而引起他人的烦恼，最终 infra 将被要求或期望进行调解
  • 功能重复，meetbot 和 purplebot 都会记录频道并以不同的位置托管存档
  • Canonical 机器人没有得到维护
• infra 当前维护的机器人可能具有人们不知道的功能。
• 可以 +2 审查并批准的机器人，在考虑到计划、停机、网关问题等因素时可能存在问题。
• 例如，Success 机器人是一个利用现有状态机器人添加的功能。
• 人们最终编写自己的机器人而不是在适用时为现有的 infra 机器人做出贡献的原因是什么？
• 完整线程

发布候选版本后主分支上的语义版本

• 发布团队假设人们在安装东西时会选择三种选项
  • 来自任何分支的标记版本。
    • 清晰，并且始终产生可重现的部署，版本随时间不同且递增。
  • 稳定分支上的未标记版本。
  • 主分支上的未标记版本
    • 选项 2 和 3 是围绕发布周期边界的一些事情。
    • 在不同的分支中产生相同的版本号，持续时间短。
    • 发布团队认为，没有人会混合选项 2 和 3，因为这会使升级变得困难。
• 一些发行版希望打包未经贡献者标记为可发布的内容。
  • 消费者
    • 他们正处于他们的开发周期中，并且希望/需要在整个周期内跟进 trunk。
    • 在一个周期中引入了许多更改，包括新功能、弃用、删除、不向后兼容等。通过提供这些持续更新的软件包，他们能够立即测试它们。
  • 打包东西需要很多工作，发行版希望尽快完成。
    • 如果发行版仅在官方稳定版本发布时才开始打包 OpenStack，那么发行版需要几个星期/几个月才能发布一个稳定的软件包。
    • 使用软件包进行部署的项目随后会因其自身的发布而延迟，以测试他们正在使用的这些软件包。（例如，TripleO、Packstack、Kolla、Puppet-OpenStack）。
• 完整线程

我们的安装指南仅涵盖 Defcore – Big Tent 呢？

• 最近，像 Manila [6] 和 Magnum 这样的项目已被安装指南接受，但我们最初遇到问题是因为它们不被 defcore 工作组认为。
  • 随着来自 big tent 的项目扩展，文档团队收到项目请求，要求接受他们的安装文档。
  • 文档团队今天维护和验证每个版本的安装文档需要大量工作，并且已经接受了 OpenStack 项目。
• 目标
  • 使安装指南易于为 big tent 中的项目做出贡献。
  • 不要让文档团队维护所有项目的安装文档。
  • 作为一名操作员，我应该能够轻松发现 big tent 中项目的安装文档。
  • 有了可访问的安装文档，项目可以希望拥有
    • 改进的采用
    • 来自错误报告的更稳定的工作，因为人们实际上能够安装和测试该项目。
• 提案：安装文档可以位于项目的仓库中，以便他们可以维护和更新。
  • 将所有这些文档源渲染到一个位置，以便于发现。
• 完整线程