跨项目专有驱动程序代码回顾

• 在巴塞罗那设计峰会上，我们讨论了专有驱动程序代码的界限问题，这是一个跨项目的挑战 [1]。
• 选项 1
  • 驱动程序导入的所有库都必须获得许可，以便软件包维护者可以重新分发，并且必须与 Apache 许可证 [2] 兼容。
  • 现有的不合规驱动程序代码需要在 Queens 版本发布前更新。
  • 驱动程序运行时未导入的代码（CLI、外部二进制文件、远程应用程序服务器）可以不具备可重新分发的特性。
• 选项 2
  • 移除所有未完全开源并包含在项目仓库中的驱动程序。
• 选项 3
  • 要求大部分业务逻辑都在开源代码中。
  • 允许使用第三方、不可重新分发的库和 CLI，它们更像是一种“RPC”类型的接口。
  • 审查人员应该能够审查驱动程序，并至少了解驱动程序执行请求的步骤。
• Jeremy Stanley 希望将选项 1 进一步发展，并提供更好的指导。我们应该建议避免驱动程序调用专有工具。一些厂商这样做是因为他们已经有一个非自由的 CLI 工具，并且避免代码成本重复。其他厂商可能这样做是为了复制其他厂商。
  • 希望拥有可重新分发的特性，是为了让 OpenStack 的下游用户不必仅仅为了使用我们的（免费！）软件与他们拥有的硬件，就必须依赖厂商。
  • 例如
    • 厂商决定停止支持专有的命令行工具
    • 您决定停止支付支持合同以下载该工具
    • 厂商消失
• 完整线程

Ocata 版本管理沟通

• 致 PTL 或代理 PTL 的志愿者
• 邮件
  • openstack-dev 邮件列表上的“[release]”主题标签将用于重要消息。
  • 倒计时邮件，包含关于重点、任务和即将到来的日期的更新。
• IRC
  • 在截止日期期间，尤其是在 #openstack-release 上保持在线。您需要配置一个 IRC bouncer 来确保这一点。
• 书面文档
  • 阅读 Ocata 周期计划 [3]。
  • 一些项目有自己的截止日期。欢迎向 openstack/release 仓库提交补丁来更新此计划。
• Ocata 周期与几个重要节日重叠。如果您计划休假，请确保您的团队中的其他人负责您的职责。请告知发布团队，以免他们等待您的 +1。
• 未能完成所需的流程步骤可能会阻止您成功满足截止日期或发布。
• 发布里程碑和截止日期是基于日期的，而不是基于功能的。日期过去，里程碑也随之过去。如果您错过了，就错过了。
• 完整线程

发布公告

• 在巴塞罗那峰会上，发布团队讨论了如何改进发布公告，因为将它们发布到 openstack-dev 和 openstack-announce 已经被证明非常嘈杂。
• 建议的解决方案是将这些公告移动到另一个邮件列表。选项是
  • release-announce
  • release-announcements
• 完整线程

POST /api-wg/news

• 将在一周内合并的 API 指南，如果没有进一步的反馈
  • 复杂的查询 [4]
  • 指定时间间隔的过滤查询 [5]
  • 澄清为什么 CRUD 不是一个很好的描述符 [6]
• 正在审查的指南
  • 定义分页指南 [7]
  • 添加 API 功能发现 [8]
• 完整线程

R-15 周倒计时

• 重点
  • 团队应该专注于完成 Newton 周期末期未完成的工作。
  • 最终确定并宣布峰会计划
  • 完成规范和蓝图
• 通用说明
  • 稳定且独立的发布已经恢复。
  • 我们在 Ocala 计划中删除了第一个里程碑之前的时间。Ocata-1 将在 R-14 期间发布。
• 发布操作
  • 发布联络员应将他们的姓名和联系信息添加到 wiki [9]。
  • 发布联络员应配置他们的 IRC 客户端以加入 #openstack-release。
  • 发布联络员应审查所有交付成果的发布模型，并在第一个里程碑之前使用补丁更新 openstack/governance。
  • PTL 应该确认 Ocala 系列社区目标 [10]
• 重要日期
  • Ocata 1 里程碑：11月17日
  • Ocata 发布计划 [11]
• 完整线程