根据 [委员会的孵化与毕业指南]，本页旨在跟踪 Manila 实现官方孵化、后续毕业以及作为核心项目提交的进展情况。
新项目要求
范围
| 状态 |
需求 |
如何满足 |
| 绿色
|
团队必须拥有明确的范围，与其他团队的范围不同 |
共享文件系统的管理不与其他项目的范围重叠。最相似的项目将是块存储，关于共享文件系统和块存储是否应属于同一项目的讨论在广泛讨论后已解决。 |
| 绿色
|
团队必须拥有使命宣言 |
位于 此处。 |
成熟度
| 状态 |
需求 |
如何满足 |
| 绿色
|
团队必须已经存在，定期开会并产出一些成果 |
该团队已经存在一年多，并且规模不断扩大。已经在线举行了 45 次每周会议，并记录了会议纪要。 |
| 绿色
|
团队应该有一位领导者，由团队贡献者选出 |
Ben Swartzlander 是领导者。Manila 团队希望按照其他项目相同的流程举行正式的 PTL 选举。 |
| 绿色
|
团队应该有明确的方式来授予 ATC（投票）状态给其重要的贡献者 |
该流程记录在 此处。 |
交付成果
| 状态 |
需求 |
如何满足 |
| 绿色
|
团队应该有明确的交付成果 |
交付成果列举在 此处 |
孵化要求
范围
| 状态 |
需求 |
如何满足 |
| 绿色
|
项目必须拥有清晰且明确的范围。 |
参见 Manila/孵化申请、Manila/项目申请。 |
| 绿色
|
项目的范围应该代表 OpenStack 整体上的一种有步骤的进展。 |
共享文件系统的管理是 OpenStack 以及大多数其他云平台中的一个关键差距。 |
| 绿色
|
项目不应无意中复制其他 OpenStack 项目中已有的功能。如果复制，则应制定明确的计划和时间表以防止长期范围复制。 |
Manila 不复制任何其他项目的功能，除了 Cinder，它是 Cinder 的一个分支。Cinder 中所有与块相关的的功能已被删除，并且仅剩余重复的代码是 LVM 驱动程序的部分内容，该驱动程序已被弃用并很快将被删除。 |
| 绿色
|
项目应尽可能利用其他 OpenStack 项目中已有的功能 |
Manila 利用 Oslo 来完成 Cinder 使用 Oslo 的许多事情。Manila 还利用 Cinder 和 Nova 在其通用驱动程序中，并且与 Neutron 的集成是 Manila 核心功能的关键。 |
成熟度
| 状态 |
需求 |
如何满足 |
| 绿色
|
项目应该有一个活跃的贡献者团队。 |
Stackanalytics 表明团队非常活跃，并且随着时间的推移变得越来越多样化。自 Juno 设计峰会以来，兴趣/贡献显著增加。 |
| 绿色
|
项目不应计划进行重大的架构重写 |
在 Icehouse 时间段进行了一次对架构的重大更改，现在我们认为我们可以在当前架构内支持所有我们计划的新功能。 |
| 绿色
|
项目 API 应该相对稳定。 |
自从添加以来，绝大多数 API 都是稳定的，并且自 Icehouse 以来，API 没有需要任何破坏性更改。所有新功能都可以作为新的 API 或与现有 API 兼容的扩展来实现。 |
流程
| 状态 |
需求 |
如何满足 |
| 绿色
|
项目必须托管在 stackforge 下（因此使用 git 作为其 VCS） |
已于 2013 年迁移到 stackforge。 |
| 绿色
|
项目必须遵守 OpenStack 协调项目接口（例如 tox、pbr、global-requirements……） |
所有这些要求都已满足。 |
| 绿色
|
项目应使用 oslo 库或 oslo-incubator（在适当的情况下） |
从 Cinder 分支以来一直如此。 |
| 绿色
|
如果项目不属于现有项目，则需要在提交孵化请求的同时提交新项目申请，并填写相应要求。 |
参见 Manila/项目申请。 |
| 绿色
|
项目必须拥有明确的核心评审团队，评审在团队成员之间分配（而不仅仅由一个人完成） |
核心团队定义明确（目前 4 人）。评审在现有成员中进行分配。我们正在积极扩大核心团队以帮助分担负担。 |
| 绿色
|
评审应遵循与 OpenStack 项目相同的标准（在 +A 之前 2 +2s） |
我们从 Icehouse 开始执行此规则。 |
| 绿色
|
项目应使用官方 openstack 列表进行讨论 |
Manila 专门使用 openstack-dev 进行电子邮件讨论，并使用适当的 freenode 频道进行聊天/会议。 |
QA
| 状态 |
需求 |
如何满足 |
| 绿色
|
项目必须有一个基本的 devstack-gate 作业设置 |
Manila 有使用 tempest+devstack 的 gate 测试。 |
文档 / 用户支持
法律要求
| 状态 |
需求 |
如何满足 |
| 绿色
|
项目必须在 Apache License v2 下授权 |
从一开始就是这样。 |
| 绿色
|
项目不应具有有效地限制项目分发或部署方式的库依赖项 [1] |
这是真的。 |
| 绿色
|
所有项目贡献者必须签署 CLA |
此要求由 gerrit 强制执行。 |
| 绿色
|
项目不应存在已知的商标问题 [2] |
NetApp 法律部门的商标搜索没有发现任何问题。 |
[1] https://wiki.openstack.org/wiki/LegalIssuesFAQ#Licensing_of_library_dependencies
[2] https://wiki.openstack.org/wiki/LegalIssuesFAQ#New_Project_Names
毕业（集成）要求
在每个周期结束时，孵化项目都会经过毕业评审，以检查它们是否准备好成为下一个开发周期的组成部分，并包含在下一个 OpenStack 集成发布中。TC 将评估项目的技术成熟度并检查许多要求，包括（但不限于）
范围
| 状态 |
操作 |
|
|
项目不得复制其他 OpenStack 项目中已有的功能 |
成熟度
| 状态 |
操作 |
|
|
项目必须拥有庞大且多样化的贡献者团队 |
|
|
项目必须完成与其他集成项目的集成工作，如 TC 在接受孵化时沟通的那样（如果适用，包括 Dashboard 集成） |
流程
| 状态 |
操作 |
|
|
项目必须拥有多样化的核心评审团队（超过 4 人） |
|
|
核心评审人员必须强制执行至少 2 +2s 才能接受更改 |
|
|
项目应与营销团队联系，以检查合适的官方名称 |
|
|
项目必须使用 OpenStack 任务、缺陷和设计跟踪器 |
QA
| 状态 |
操作 |
|
|
项目必须有一个 devstack-gate 作业正在运行。此 gate 作业应使用 devstack 安装项目，然后运行 tempest 测试。此作业应运行并在项目的 check 和 gate 管道中投票。不要求此作业为它所依赖的项目运行。这表明在毕业后将项目添加到集成 gate 很容易。 |
|
|
项目必须具有良好的单元测试和功能测试覆盖率 |
|
|
项目必须与所有当前 OpenStack 支持的 Python 版本兼容 |
|
|
项目应具有处理传入错误的良好记录 |
文档 / 用户支持
| 状态 |
操作 |
|
|
项目必须具有最终用户文档，例如 API 使用、CLI 使用、Dashboard 使用 |
|
|
项目应具有安装文档，提供与 OpenStack 其他项目类似的集成安装/部署方式，包括所有选项的配置参考信息 |
|
|
项目应具有提供用户支持的良好历史记录（在 openstack@ 邮件列表中和在 Ask OpenStack 上） |
发布管理 / 安全
| 状态 |
操作 |
|
|
项目必须遵循至少两个常见的里程碑（至少从 X-2 开始遵循常见周期） |
|
|
项目必须至少有一个里程碑由发布管理团队处理（至少是 X-3 里程碑） |
|
|
项目必须提供一个 2 人以上的团队来处理项目特定的漏洞流程 [3] |
[3] https://wiki.openstack.org/wiki/Vulnerability_Management
