团队和仓库标签¶

https://governance.openstack.org/tc/badges/qa-specs.svg

QA Specs 仓库¶

这是一个 git 仓库，用于对 OpenStack 项目中的 QA 增强进行设计评审。这提供了一种确保在解决问题的方法在早期获得所有人的认可的能力。

该仓库包括 Tempest 和 DevStack 项目。

仓库结构¶

仓库的结构如下

specs/
    devstack/
        implemented/
    other
        implemented/
    tempest
        implemented/

预期工作流程¶

在 tempest、devstack 或 other 蓝图仓库中创建一个蓝图草稿
向 qa-specs 仓库提出评审（确保提交消息中包含 bp:blueprint_name。DevStack 规范应进入 devstack/ 子目录，但否则遵循相同的流程。）
将 阅读完整规范 链接到规范的 gerrit 地址
将拟议事项提交到 openstack-qa 会议进行总结
qa-core 成员和其他人对提案进行评审
迭代直到评审被批准或拒绝

一旦评审被批准…

更新蓝图，将蓝图的摘要文本复制到那里
将 阅读完整规范 链接到规范的 git 地址
盈利！

重新审视规范¶

我们并不总是第一次就做到完美。如果我们意识到需要重新审视一个规范，因为情况发生了变化，或者我们现在有了更多的了解，或者出现了一个我们应该接受的新想法，我们将通过提出对相关规范的更新来管理它。

在实践中学习¶

这是一种尝试新方法，因此我们一开始将采用低流程的方式来确定我们下一步该怎么做。预计在一段时间内，这项工作会表现出一定的灵活性。

Tempest 规范用于新测试¶

如果您正在编写新的规范以改进 Tempest 中的测试覆盖率，规范中包含的内容的要求会略微宽松且与其他提案不同。这是因为更多测试的蓝图更多的是跟踪一个地方的努力并为方便评审在 gerrit 中分配统一的主题，它不太关注实现细节。关于新测试的蓝图/规范应该只针对总体开发工作而打开。例如，为一个项目添加测试只需要一个蓝图。

这些工作中的大部分需要一种跟踪 Launchpad 之外工作项的方法。Etherpad 和 Google Docs 都已被非常成功地用于此目的。目标是列出所有需要编写的测试，并允许人们标记他们打算致力于特定的测试。这可以防止重复工作，并提供整体状态跟踪。像 Etherpad 或 Google Docs 这样的外部工具更适合此目的，因为它们允许并发使用和比 Launchpad 更动态的编辑。

关于新测试的规范的拟议变更部分中唯一需要的细节是

正在测试的内容以及蓝图将涵盖的范围
正在使用的外部工具来跟踪开发。
- 如果未使用外部跟踪，请解释原因。

DevStack 规范¶

DevStack 的规范分为几个大类

支持新的 {项目|驱动程序|酷炫小工具}

关于“此支持是否属于 DevStack 仓库？”的讨论应该在此处进行。
重大的重构

这些类型的更改的主要部分之一是对向后兼容性和 Grenade 影响的分析。

现有的模板大多适用于 DevStack 的使用，快速的 s/tempest/devstack/ 可以处理大部分更改。

团队和仓库标签