谷歌工程師 Russ Cox 在週一給 golang-dev 的郵寄清單中，該公司決定以後有關 Go 程式語言的每項改動都需經由 2 名谷歌員工審查以後（以前為 1 名），才可以面向使用者釋出。但其並未透露谷歌作出該決策的具體動機。
出於合規性和供應鏈安全的考慮，谷歌最近重新審視了我們在所有環境中使用的程式碼審查要求，包括內部開發和開源。我們現在需要讓兩名 Google 員工在將每個更改傳送給使用者之前對其進行稽核，這對於我們的大多數工具來說意味著在 Gerrit 中提交（「go get」和「gotip download」等工具以及 自動部署直接從 Gerrit 中讀取）。
Cox 指出，他們將於本月晚些時候增加一個新的 Gerrit 提交要求。即在每項修改提交之前，必須有 2 名谷歌員工上傳或貢獻一個積極的 Code-Review 投票（+1 或 +2）；以取代目前的 計劃：該計劃於 2020 年 8 月實施。除了在 CL submissions 上的兩個"Code-Review" label 外，還增加了一個"Trust" label。這樣做是為了防止 CL 被劫持或傀儡賬戶，並防止具有"approver"身份的作者批准和提交他們自己對 Go 程式碼庫的修改。
任何參與 Go 開發的人都可能被授予「approver」權力來審查和提交程式碼更改列表。根據內容，當一項更改接近決策時，審查員會對其進行投票。Gerrit 投票系統涉及 -2 到 +2 範圍內的整數：
- +2 更改被批准合併。只有 Go 維護者可以投 +2 票。
- +1 更改看起來不錯，但審查者在批准之前要求進行較小的更改；或者他們不是維護者並且無法批准它，但希望鼓勵批准。
- -1 這個改動現在的狀態並不好，但可能是可以修復的。-1 投票將始終有註釋解釋為什麼更改是不可接受的。
- -2 更改被維護者阻止，無法獲得批准。同樣，將有一條評論解釋該決定。
「至少要有兩個維護者同意該更改，且其中至少一名維護者必須 +2 該更改。第二個維護者可能投了 Trust+1 的投票，這意味著更改看起來基本沒問題；但維護者還沒有完成 +2 投票所需的詳細審查。」
Cox 表示，他計劃在 GerritAccess 頁面上新增一些說明。即，「每個 CL 都需要來自一名 approver 的 code review (Code-Review+2) 和兩名 Google 員工的參與；要麼是作為程式碼上傳者，要麼是作為審查者投票，至少是 Code-Review+1。要求多人確保不能從單個被盜帳戶單方面提交程式碼。一旦審查獲得 Code-Review+2 和必要的 Google 參與，它就可以由任何 approver 提交。所有這些規則都由 Gerrit 伺服器強制執行。」
針對這一變更，Go 貢獻者、電腦科學家 Alberto Donizetti 則在郵寄清單中表示，這一變化有效地限制了 Committer 群體，使其只限於谷歌員工。
當被質疑此次 Go 政策的改變是否使會得非 Google 維護者投出 +2 合併批准票毫無意義時，Cox 進行了否認並表示，「我們完全期望 CL 將繼續像今天一樣只接受非 Google 員工 Code-Review+2 審查」。並補充稱，預計在完成深入的 Code-Review+2 之後，因等待 Code-Review+1 的認可而產生的任何延遲將是最小的。
此前，Go 官方部落格曾介紹了他們 指出，此次增加第二名谷歌員工的審查則擴大了現有的保障措施，谷歌此舉也許可以多提供一層保護措施，防止涉及員工叛變之類的威脅情況發生。
更多詳情可。