OpenStack Masakari 规范

这个 git 仓库用于存放 Masakari 项目的已批准设计规范。规范的评审在 gerrit 中进行，流程类似于我们评审和合并代码本身的方式。

这个仓库的布局是

specs/<release>/

其中包含两个子目录

specs/<release>/approved: 已批准但尚未实现的规范 specs/<release>/implemented: 已实现规范

规范的生命周期

提出规范的开发者应在 approved 目录中提出新文件。masakari-core 将以 OpenStack 项目的常用方式评审该变更，最终如果达成共识，则会合并。此时 Launchpad 蓝图也被批准。开发者随后可以自由地提出代码评审以实现他们的规范。这些评审应确保在提交消息中引用 Launchpad 蓝图，以便跟踪。

一旦功能的全部代码合并到 Masakari 中，Launchpad 蓝图就会被标记为完成。作为已批准规范的开发者，您有责任在所有必需的补丁合并后标记您的蓝图为完成。

定期地，masakari-core 的某人会将已实现的规范从 approved 目录移动到 implemented 目录。个人开发者也可以为他们已实现的规范提出此移动。在执行此操作时创建重定向非常重要，这样可以避免破坏指向已批准规范的现有链接。重定向不是符号链接，它们是在 sphinx 消耗的文件中定义的。一个示例在 specs/ocata/redirects。

这种目录结构允许您了解我们考虑过要做什么、决定要做什么以及实际完成什么。对特定版本的功能感兴趣的用户应仅参考 implemented 目录。

示例规范

您可以在 specs/ocata-template.rst 中找到一个示例规范。

使用 gerrit 和规范单元测试

有关使用 gerrit 的更多信息，请参阅 https://docs.openstack.org/infra/manual/developers.html#development-workflow

为了验证规范在语法上是否正确（即，获得更多 Jenkins 结果的信心），请执行以下命令

$ tox

运行 tox 后，文档将以 HTML 格式在 doc/build/ 目录中提供以供查看。