加速审批¶

通常情况下，TripleO 遵循标准的“2+2”评审标准，但在某些情况下，我们希望做出例外。本策略旨在记录这些例外情况。

问题描述¶

核心评审人员的时间非常宝贵，而且永远不够用。在某些情况下，对补丁进行 2+2 评审是对核心时间的一种浪费，因此我们需要合理地决定何时做出例外。虽然核心评审人员始终可以自行判断何时合并或不合并补丁，但列出一些可以接受甚至期望使用单个 +2 批准的特定情况可能会有所帮助。

部分信息已经存在于 wiki 中，但 wiki 的未来存在不确定性，将策略放在可以进行评审的地方更好。

在以下情况下，核心可以并且应该在没有第二个 +2 的情况下批准补丁

该更改在之前的补丁集中有多个 +2，表明其他核心同意整体设计是好的，并且自那些 +2 之后对补丁的任何更改都必须是微小的实现细节 - 琐碎的 rebase、小的语法更改或注释/文档更改。
由另一位核心评审人员提出的 backport。Backport 在合并到 master 时已经过设计评审，因此如果两位核心同意 backport 是好的（一位提出，另一位评审），则可以使用单个 +2 评审进行合并。
机器人提出的需求更新。
机器人提出的翻译更新。（另请参阅评审翻译导入。）

补丁的共同作者可以 +2 该补丁，但要合并补丁，至少需要一位未列为共同作者的核心的 +2。例如，如果核心 A 推送了一个补丁，核心 B 和 C 作为共同作者，那么核心 B 和核心 C 都可以 +2 该补丁，但需要另一位核心 +2 才能合并该补丁。

如果补丁具有必需的 2 个 +2 和 CI 通过，核心可以自主批准其提交的补丁。但是，如果对补丁存在任何争议，例如在具有 2 个 +2 和未解决的 -1 的更改上，则不应这样做。

本策略不影响 CI 要求。补丁在合并之前仍然必须通过 CI。

该策略已经生效一段时间了，但并非每个 TripleO 核心都知晓，因此只是将其书面记录在官方位置以供参考。

该策略已经生效。

确保所有核心都知晓该策略。策略合并后，应向 openstack-dev 发送一封电子邮件，提及该策略。

注意

本作品采用知识共享署名 3.0 非移植许可协议授权。 https://creativecommons.org/licenses/by/3.0/legalcode