OpenStack 博客 关于 OpenStack 的所有文字记录。

在过去的几个月里，技术委员会一直在讨论解散集成发布的二元概念，并调整我们的项目结构以适应 OpenStack 社区协作的未来需求。 一份规范被编写出来，以描述改革的理由及其目标。在过去几周里，OpenStack 技术委员会批准了一系列首批变更，这些变更影响了 OpenStack 上游团队和我们社区开发的项目的组织方式。

项目团队

这些变更中的第一项是从“项目组”（programs）过渡到“项目团队”（project teams）。我们之前围绕主题项目组组织 OpenStack 中的工作，例如“计算”（Compute）、“基础设施”（Infrastructure）或“部署”（Deployment）。这造成了一些问题，包括术语与“商标项目组”的冲突，或者命名混淆（“计算”既是 Nova 的官方名称，也是生产它的开发团队的名称）。但最重要的问题是它具有排他性：只能有一个“部署”项目组。任何替代解决方案都无法发展和证明其价值，除非被现任团队采用。这扼杀了创新，并使有价值的项目，可以说是在 OpenStack 社区中开发的，永远无法进入“OpenStack”。

通过将它们称为项目团队，并以其主要产品的代码名称命名它们（“Nova 团队”、“TripleO 团队”），我们避免了这种排他性。我们还真正地称呼团队，就像上游的每个人称呼它们一样。这并不意味着我们将为每个现有的项目团队拥有替代项目团队：显然，竞争对基础设施团队等只有一个团队的团队来说没有意义。 但允许一些竞争发生，让我们可以在为我们的用户带来价值的地方培养创新。

项目团队的新要求

第二个变更在于新工作组被正式接受为 OpenStack 项目团队的要求。 新项目过去有复杂且非常主观的要求，包括避免与现有项目的功能范围重叠。 对于正在开发软件交付成果的项目，我们会评估交付成果的成熟度并判断其与“集成发布”的其余部分的潜在契合度。 这造成了许多问题（详细信息请参见 该规范，供感兴趣的人参考），最终导致我们在 Juno 周期内完全无法接受新的工作组。

新的要求更多的是社会性的而非技术性的。目标是确定一个项目团队是否“我们中的一员”：他们是否帮助实现 OpenStack 的使命？他们是否遵循 OpenStack 方式（四个开放）？他们是否像其他 OpenStack 项目一样进行日常开发？他们是否遵循我们的开发周期？他们是否使用 openstack-dev 邮件列表并参与我们的设计峰会？那么他们显然是 OpenStack 社区的一部分，他们生产的软件应该被识别为“OpenStack 项目”。

我们将从现在开始接受新的项目团队申请，尽管技术委员会预计最初会按顺序缓慢地处理它们，因为我们仍在完善要求和申请流程。我们预计在温哥华的 Liberty 设计峰会之前，将增加许多新的项目团队。

有些人担心新的项目团队突然涌入会扰乱设计峰会。我的回答是，我们实际上已经在设计峰会上有了不仅仅是官方项目组，我们已经为那些显然是我们社区一部分的项目提供了时间和空间。这只是让事情更清楚。与拟议的变更设计峰会格式一起，我们相信该活动可以经受住这种变化。

不再有通往集成发布的孵化阶梯

第三个变更是我们开始将“集成发布”概念分解为一组更明确定义的标签。 正如 该规范中所解释的，二元的“集成发布”属性最终对不同的人意味着不同的东西。 最初只是意味着“在同一日期一起发布”。 但由于这是唯一的属性，人们推断出稳定性、成熟度或共同开发过程的必要模块，而没有实际的采用情况。 这造成了许多困惑，并且使其成为一个非常理想的徽章，而不是一个技术属性，导致一个越来越大的项目组合，项目并非以相同的方式被 我们的 用户使用。 现在是时候让这个单一且二元的概念消失，并被一系列更精确定义的属性所取代，最终为我们生态系统中的项目提供更丰富的描述。

我们创建了一个框架来定义这些标签。作为第一步，为了确保无缝过渡，我们创建了一个“集成发布”标签来描述将在 Kilo 周期结束时一起发布的项目列表。在未来几个月里，我们将开始定义各种“集成发布”概念的标签，并将它们应用于符合其要求的项目。这些标签将帮助用户做出更明智的决策。

由于这将最终使集成发布成为一个过时的概念，我们还取消了“孵化”期。 孵化期是项目学习流程和整合一系列 要求，在我们确信它们能够在与其他“集成项目”同时发布而不会危及现有项目之前。 由于我们正在取消“集成发布”作为单一目标，我们也在取消缓慢通往它的孵化阶梯。 然而，定义严格的质量标准的工作仍在继续，通过定义特定的 QA 相关标签和更直接的 项目团队指导。

现有孵化项目会怎样？嗯，它们仍然是完整的 OpenStack 项目，由官方 OpenStack 项目团队制作。我们将根据我们定义和引入的标签来应用标签（或不应用标签）。

核心呢？

OpenStack “核心”是一组由 OpenStack 基金会董事会（更确切地说，其 Defcore 子委员会）定义的规则，与特定的商标项目组相关联（想想：为了将您的解决方案标记为“OpenStack Powered”而需要实现什么）。Defcore 过去会根据“集成发布”项目列表来构建他们的“核心”规则，那么这些变化会如何影响它？

首先，Defcore 已经从简单的核心项目列表转向了基于能力和所需代码部分的方案，这些方案可以应用于多个不同的商标项目组。最近通过的新章程措辞仍然要求 Defcore 从技术委员会批准的项目列表中选择所需的代码部分，因此技术委员会仍然预计需要向 Defcore 提供项目列表。我们可能会将我们的答案表达为特定的标签，以便与其它属性分离，并具有与商标项目组特定需求相一致的特定弃用规则。

关注呢？

随着 OpenStack 项目团队和交付软件数量的可能增加，自然会担心这会分散对基本项目的注意力。 我们不认为会这样。 首先，这不是零和游戏：承认更多的项目团队是社区的一部分，会将新的力量带入我们的社区，而不是人为地将它们排除在外。 其次，关键的项目集将作为其他项目都必须依赖的基础集出现。 这些基础集将比当前的集成发布小得多，因此我们将更容易集中精力。 过载且不断增加的“集成发布”迫使我们越来越分散注意力，而这种演变将 使我们能够更专注于 基础组件。

接下来是什么？

改革的下一步是开始定义将取代“集成发布”单一概念的标签。例如，我计划引入一系列标签来描述每个项目的发布模型。他们是否由发布管理团队协调以确保按时发布？他们只是采用通用的发布计划并尽力达到日期？他们是否遵循自己的基于功能的计划，试图与 Kilo 发布日期相匹配？或者他们只是在他们认为合适的时候发布？这些标签将为我们的下游用户提供比我们目前提供的更丰富的信息。

但这只是一个例子。 目标是让我们的社区提出对他们有用的标签，并提供记录的标准。 技术委员会不应拥有标签定义的排他权。 我希望我们的运营商、发行版和最终用户讨论对他们有用的属性，并提出相应的标签。 技术委员会也不应拥有将标签与项目关联的排他权：标签应由最了解的人应用（并且应用者实际上是每个标签定义的一部分）。 技术委员会只是监督标签框架，我们所有人都必须使其尽可能有用，以便浏览我们不断增长的生态系统。