跨项目汇总
经过充分讨论和审查时间后，我们合并了几个跨项目规范。我们现在正在 启用 Python 3 用于应用程序集成测试，并修改了 需求管理设计，请点击进入 specs.openstack.org 阅读每个规范的详细信息。
目前有很多关于可能退役 Stackforge 的讨论，目的是为了减轻项目从 Stackforge 组织迁移到 OpenStack 组织时产生的 github 组织重命名的工作量。我们正在讨论和辩论 Stackforge 作为提供的 CI 工作流程的用例。到目前为止，我们观察到四类 Stackforge 项目
- OpenStack 项目使用 stackforge 进行孵化，直到准备就绪
- 只想找个地方存放，并且没有足够的精力向 TC 提出申请的项目
- 在 OpenStack 世界中，明确不想受 TC 监管的项目（Akanda, StackTach）
- 已停止的项目
我们希望找到一个解决方案，以便仍然可以为所有需要它的项目提供服务，但减轻开发人员和系统管理员在项目重命名方面的工作负担。我们希望听到关于这些用例的意见，以及 Stackforge 是否有其他用例，请在 review 上评论。
我们需要更多的跨项目主席，尤其是在这个月，请参阅 https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Chair_rotation 报名，并与 Thierry Carrez 沟通如何运行，他很乐意通过电子邮件提供期望和培训。
关于启动套件的健康辩论
在过去的几周里，我们一直在讨论哪些项目应该获得启动套件标签。在一系列审查中，我们仍在辩论和讨论是否将 OpenStack Networking 项目 neutron 以及 OpenStack 块存储项目 cinder 纳入其中。
关于网络的一些背景和历史，nova 团队过去曾尝试弃用 nova-network，但多年来未能完成弃用。在创建 API 时，neutron 团队没有保持与 nova API 兼容的调用集（例如 cinder 实现了一个与原始计算 API 调用相同的 v1 Volume API）。从 nova-network 到 neutron 有一个升级路径，但它并非无缝。在某些配置中，由于后端没有完全对应的，现在部署可以停留在 nova-network 而不是部署 neutron。但是，新的 Networking 指南有一个 使用提供商网络和 Linux Bridge 的场景，对于许多部署来说是一个很好的起点。一个建议是将该场景添加到安装指南中，以帮助记录起点。因此，我们继续进行各种 审查 以应用这些标签。
正在申请流程中的项目
Compass 作为项目在本周的 TC 会议上进行了讨论。一个问题出现了，由于它是一个通用的部署框架，并且不限于 OpenStack，它是否需要成为一个 OpenStack 项目。此外，还有一个 API 资源名称可能引起混淆的问题，我们还要求团队在会议和沟通中更加开放。
另一个仍在 TC 审查队列中的项目是 RPM 和打包团队或团队。我们正在等待更新的规范，更多的讨论和会议进展，以及 PTL（或两个？）和范围定义，以便我们可以再次审查。例如“这是否是打包的两个团队还是一个团队？”等问题仍然存在。
M 名称的探索仍在继续
投票中的前三个名称已被排除，因为存在商标困难或文化尊重问题。请关注 openstack-dev 邮件列表，以了解 M 名称。我们将 在未来在发布名称中明确地理位置，并继续改进开放的命名流程。
发表评论