跨项目汇总
经过充分讨论和审查时间后，我们合并了几个跨项目规范。我们现在正在 启用应用程序集成测试的 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 沟通如何运行，他很乐意通过电子邮件提供期望和培训。
关于启动套件的健康辩论
在过去的几周里，我们一直在讨论哪些项目应该获得 starter-kit 标签。在一系列审查中，我们仍在辩论和讨论是否包含或排除 OpenStack Networking 项目 neutron 以及 OpenStack 块存储项目 cinder。
关于网络的一些背景和历史，nova 团队过去曾试图弃用 nova-network，但多年来未能完成该弃用。在创建 API 时，neutron 团队没有保持与 nova API 兼容的调用集（例如 cinder 实现了一个与原始计算 API 调用相同的 v1 Volume API）。从 nova-network 到 neutron 有一个升级路径，但它并非无缝。在某些配置中，由于后端没有精确的类似物，部署现在可以停留在 nova-network 而不是部署 neutron。但是，新的 Networking Guide 有一个 使用提供商网络和 Linux Bridge 的场景，对于许多部署来说是一个很好的起点。一个建议是将该场景添加到安装指南中，以帮助记录起点。因此，我们继续致力于各种 review 以应用这些标签。
正在申请流程中的项目
Compass 作为项目在本周的 TC 会议上进行了讨论。一个问题出现了，由于它是一个通用的部署框架，并且不限于 OpenStack，它是否需要成为一个 OpenStack 项目。还有一个 API 资源名称可能引起混淆的问题，然后我们还要求团队在会议和沟通中更加开放。
另一个仍在 TC 审查队列中的项目是 RPM 和打包团队或团队。我们正在等待更新的规范、更多讨论和会议中的进展、PTL（或两个？）以及范围定义，以便我们可以再次审查。诸如“这是否是打包的两个团队或一个团队？”之类的问题仍然存在。
M 名称探寻仍在继续
投票中的前三个名称由于商标困难或文化尊重问题已被淘汰。请关注 openstack-dev 邮件列表，以了解 M 名称。我们将 在未来在发布名称中明确地理位置，并继续致力于开放的命名流程。
