Spec 评审流程¶
记录现有的流程，以帮助评审人员，特别是新手，了解如何评审 spec。这是将现有的 wiki 文档迁移到策略中。
问题描述¶
在批准 spec 时应格外小心。批准的 spec 以及相关的蓝图表明，提议的变更对 TripleO 项目具有一定的优先级。我们不希望出现大量批准的 spec 却无人拥有或正在处理的情况。我们还希望确保我们的 spec 和蓝图易于理解，并具有足够的细节来有效传达变更的意图。沟通越有效，我们从更广泛的社区获得有意义的反馈的可能性就越大。
策略¶
为此，我们在评审和批准 spec 时应注意以下清单：
来自相关方的广泛反馈。
我们应尽最大努力从运维人员、非 TripleO 开发人员、最终用户以及更广泛的 OpenStack 社区获取反馈。
向适当的邮件列表发送邮件，例如 opentack-operators 和 openstack-dev，以征求反馈。在邮件列表中回复反馈，但也要鼓励直接在 spec 本身发表评论，因为其他 spec 评审人员更容易找到这些评论。
总体共识
检查 spec 中是否存在普遍共识。
评审人员是否同意此变更对 TripleO 具有意义？
如果他们对该变更没有既得利益，他们是否至少没有反对该变更？
审查旧的补丁集，以确保已解决所有问题
是否有评审人员在之前的补丁集中提出了未解决的异议？
是否有潜在的陷阱被指出但未解决？
影响/安全性
确保 spec 中的各种“影响”（最终用户、部署者等）和“安全性”部分都有内容。
这些部分不仅仅是在理解实现和提议的变更后可以忽略的部分。它们实际上是最重要的部分。
如果这些内容获得了反馈，那会很好。如果没有，这可能是一个好迹象，表明作者和/或评审人员尚未仔细考虑这些部分。
易于理解性
对于熟悉该项目的评审人员来说，spec 应该易于理解。虽然实现可能包含并非每个人都能理解的技术细节，但总体提议的变更应该能够被一般熟悉 TripleO 的人理解。通常熟悉 TripleO 的人可能是那些运行过 undercloud 安装、贡献过一些代码或参与过评审的人。
为了帮助理解，在指出了语法错误后，通常应更正这些错误。但要注意，即使是语法错误也可能导致分歧，因为指出语法错误的人本身也可能犯错。不要在解决语法错误的争议上浪费时间。
实现
实现是否合理？
是否有替代实现，也许更容易实现，如果是这样，是否已在“替代方案”部分中列出？
spec 中是否列出了不考虑替代方案的原因？
所有权
spec 作者是否是主要负责人？
如果不是，主要负责人是否已审查过 spec，或者至少评论说他们同意他们是主要负责人？
评审人员工作量
spec 会变成代码库中的补丁。
对 spec 的 +2 意味着核心评审人员打算审查与该 spec 相关的补丁，以及他们作为评审人员的其他核心承诺的工作量。
核心评审人员对 spec 的 +1 表示核心评审人员不一定承诺审查该 spec 的补丁。
即使 spec 还涉及其他仓库和专业领域，也可以给出 +2。我们可能不希望合并跨越多个专业领域的任何 spec，除非每个组的代表都添加了他们的 +2。
是否有其他（可能不是核心）评审人员自愿审查实现 spec 的补丁？
应该有足够数量的核心评审人员自愿超出他们通常的评审工作量（通过他们的 +2 表示）来审查相关的补丁。 “足够数量”取决于具体的 spec 和变更的范围。
如果评审人员表示他们将审查 spec 的补丁而不是他们原本要审查的补丁，那并没有什么帮助，实际上对整个项目是有害的。
替代方案与历史¶
这是将已经达成的策略从 wiki 迁移过来。
实现¶
里程碑¶
无
工作项¶
一旦策略合并，应向 openstack-dev 发送一封电子邮件，引用本文档。
参考资料¶
修订历史¶
发布名称 |
描述 |
|---|---|
Ocata |
从 wiki 迁移 |
注意
本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode
