是时候对你的项目做出一些断言了

• 技术委员会定义了一系列“assert”标签，允许项目团队对自己的交付成果做出断言
  • assert:follows-standard-deprecation
  • assert:supports-upgrade
  • assert:supports-rolling-upgrade
• 更多信息请阅读其定义 [1]
• 更新项目.yaml [2]，其中包含适用于你项目的标签。
• OpenStack 基金会很快将在项目导航器 [3] 中使用“assert”标签。

将稳定的维护定义为独立的 OpenStack 项目团队 (续)

• 继续上周的讨论 [4]…
• 负面意见
  • 没有足够的工作来证明需要一个专门的“团队”。
  • 这种改变不太可能对现状带来有意义的改善，或者带来突然的新资源。
• 正面意见
  • * 一个授权的团队可以处理新的协调任务，例如更直接地参与统一跨团队的稳定分支规则，或者生产工具。
  • 发布管理不再与稳定分支重叠，因此将其置于该 PTL 下会限制效率。
  • 强化品牌（通过赋予其自己的团队）可能会鼓励更多组织为其投入新的资源
• Matt Riedemann 提出领导该团队。

R-19 周发布倒计时，11月23-27日

• Mitaka-1 里程碑计划于 12月1-3日。
• 团队应该…
  • 完成 Liberty 周期末遗留的不完整工作。
  • 最终确定并宣布峰会上的计划。
  • 完成规范和蓝图。
• openstack/release 仓库将用于管理 Mitaka 1 里程碑标签。
• Reno [5] 将取代 Launchpad 用于跟踪已完成的工作。确保在此周期完成的任何发布说明都提交到你的主分支之前，再提出里程碑标签。

新的 API 指南，供跨项目审查

• 以下内容将很快合并
  • 添加 API 微版本指南的介绍 [6]。
  • 添加分页参数的描述 [7]。
  • 关于错误的指南 [8]。
• 这些将在下一次跨项目会议 [9] 上讨论。