Go限制Committer组？每项更改都需要经过两名Google员工（以前是1名）的审核，然后才能发布给用户。但并未透露谷歌做出这一决定的具体动机。出于合规性和供应链安全方面的考虑，谷歌最近重新审视了我们在所有环境中使用的代码审查要求，包括内部开发和开源。我们现在需要让两名Google员工在将每个更改发送给用户之前对其进行审核，对于我们的大多数工具而言，这意味着在Gerrit中提交（“goget”和“gotipdownload”等工具以及直接从Gerrit读取的go.dev自动部署）.Cox指出，他们将在本月晚些时候添加新的Gerrit提交要求。即，在提交每次修订之前，必须有2名Google员工上传或贡献正面的代码审查投票（+1或+2）；取代当前的Trust+1计划：该计划于2020年8月实施。除了CL提交上的两个“Code-Review”标签外，还添加了一个“Trust”标签。这样做是为了防止CL劫持或伪造帐户，并防止具有“批准者”状态的作者批准和提交他们自己对Go代码库的更改。任何参与Go开发的人都可以被授予“批准者”权限来审查和提交代码变更列表。根据目前的Go文档内容，当更改接近决定时，审阅者对其进行投票。Gerrit投票系统涉及-2到+2范围内的整数：+2更改被批准合并。只有Go维护者可以投票+2。+1改动看起来不错，但是reviewer要求稍微改动一下才批准；或者他们不是维护者，无法批准，但希望鼓励批准。-1此更改目前状态不佳，但可能可以修复。-1票总是会有评论解释为什么更改是不可接受的。-2更改被维护者阻止，无法批准。同样，将有一条评论解释该决定。“至少有两名维护者必须同意更改，并且至少其中一名维护者必须为更改+2。第二名维护者可能已投票信任+1，这意味着更改看起来基本没问题；但维护选民尚未完成审查+2投票所需。Cox说他计划在GerritAccess页面上添加一些说明。即，“每个CL都需要一个approver的codereview（Code-Review+2）和两个Googler的参与；要么作为codeuploaders，要么作为reviewervote，至少Code-Review+1。需要多人参与确保代码不能从单个受感染的帐户单方面提交。一旦审核收到Code-Review+2和必要的Google参与，它就可以由任何批准者提交。所有这些规则都由Gerrit服务器执行。为了响应这个更改，Go贡献者和计算机科学家AlbertoDonizetti在邮件列表中表示，此更改有效地将Committer组限制为Google员工。当来自非Google维护者的+2合并批准投票毫无意义时，Cox否认并说：“我们完全期望CL将继续像今天一样只接受来自非Google员工的Code-Review+2评论”，并补充说，预计在完成深入的Code-Review+2之后，由于等待Code-Revi的批准ew+1将是最小的。此前，Go官方博客已经介绍了他们针对供应链攻击的缓解措施。TheRegister指出，将第二名谷歌员工加入审查扩大了现有的保障措施，谷歌此举可能会提供额外的保护层，以防止涉及员工叛逃的威胁。本文转自OSCHINA本文标题：Go限制Committer组？每次改动需要2个谷歌员工审核本文地址：https://www.oschina.net/news/190022/google-go-double-sign-off
