TripleO 评审标准¶
由于这不是需要在代码中实现的规范，因此没有启动板蓝图。
与许多 OpenStack 项目一样，TripleO 通常接收到的项目变更比核心评审人员能够评审和批准的变更更多。因此，优化评审人员的带宽非常重要。本规范提出了一些在巴黎 OpenStack 峰会上讨论的评审流程变更，旨在尽可能最佳地利用核心评审人员的时间。
评审人员在评审给定的变更时，主要关注两个方面：设计和实现。评审的设计部分涵盖诸如变更是否符合项目的整体方向以及新代码是否以合理的方式组织等问题。评审的实现部分将深入到更小的细节，例如是否正确使用语言功能以及评审设计部分标识的代码的各个部分是否按预期工作。
通常首先考虑设计，然后评审人员将深入到所选设计的实现细节。
问题描述¶
在变更的生命周期早期，通常会就给定变更的整体设计达成一致。然后，设计的实现可能会被多次调整（由于重新提交或评审人员指出的具体问题），而不会对整体设计进行任何更改。 很多时候，这些实现细节是小的更改，不应该需要大量的评审工作，但由于我们当前的 2 +2 标准，在变更可以被批准之前，评审人员经常不得不不必要地重新审查变更，即使是审查中涉及的所有人都赞同该变更。
提议的变更¶
概述¶
在适当的情况下，允许核心评审人员批准变更，即使最新的补丁集没有 2 +2。具体来说，应在以下情况下使用此方法
变更在过去的补丁集中已经获得多个 +2，表明其他评审人员同意该变更的整体设计良好。
自获得 +2 的补丁集以来，对变更的任何进一步更改都应仅为实现细节——微不足道的重新提交、小的语法更改或注释/文档更改。任何更重要的更改都将使此选项失效。
与往常一样，核心评审人员应运用他们的判断力。如有疑问，等待 2 +2 批准变更始终是可以接受的，但此新策略旨在使在上述情况下单方面批准变更在社会上是可以接受的。
以这种方式批准变更时，最好留下评论解释为什么在没有 2 +2 的情况下批准了该变更。
替代方案¶
还讨论了允许对“微不足道”的更改进行单个 +2，但一些与会者对此表示担忧，认为该策略可能会弊大于利，特别是由于“微不足道”的更改本质上不需要大量的评审，因此不会占用评审人员太多的时间。
安全影响¶
应该最少或没有。如果补丁集之间的更改足以产生安全影响，则此策略不适用。
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
核心评审人员将减少重新审查他们已经投票赞成的补丁的时间，并且贡献者应该更容易地合并他们的补丁，因为他们不必在重新提交和小的更改之后等待太久。
实现¶
负责人¶
- 主要负责人
bnemec
- 其他贡献者
所有核心成员都应审查并在他们的评审中实施本规范
工作项¶
将商定的指南发布到比规范更永久的地方。
依赖项¶
无
测试¶
无
文档影响¶
需要为核心评审人员创建一个新的文档以供参考。
参考资料¶
https://etherpad.openstack.org/p/kilo-tripleo-summit-reviews
