谷歌工程師 Russ Cox 在周一給 golang-dev 的郵件列表中宣布，該公司決定以后有關(guān) Go 編程語言的每項改動都需經(jīng)由 2 名谷歌員工審查以后(以前為 1 名)，才可以面向用戶發(fā)布。但其并未透露谷歌作出該決策的具體動機。

出于合規(guī)性和供應(yīng)鏈安全的考慮，谷歌最近重新審視了我們在所有環(huán)境中使用的代碼審查要求，包括內(nèi)部開發(fā)和開源。我們現(xiàn)在需要讓兩名 Google 員工在將每個更改發(fā)送給用戶之前對其進行審核，這對于我們的大多數(shù)工具來說意味著在 Gerrit 中提交(“go get”和“gotip download”等工具以及 go.dev 自動部署直接從 Gerrit 中讀取)。

Cox 指出，他們將于本月晚些時候增加一個新的 Gerrit 提交要求。即在每項修改提交之前，必須有 2 名谷歌員工上傳或貢獻一個積極的 Code-Review 投票(+1 或 +2);以取代目前的 Trust+1 計劃：該計劃于 2020 年 8 月實施。除了在 CL submissions 上的兩個"Code-Review" label 外，還增加了一個"Trust" label。這樣做是為了防止 CL 被劫持或傀儡賬戶，并防止具有"approver"身份的作者批準(zhǔn)和提交他們自己對 Go 代碼庫的修改。

任何參與 Go 開發(fā)的人都可能被授予“approver”權(quán)力來審查和提交代碼更改列表。根據(jù)當(dāng)前的 Go 文檔內(nèi)容，當(dāng)一項更改接近決策時，審查員會對其進行投票。Gerrit 投票系統(tǒng)涉及 -2 到 +2 范圍內(nèi)的整數(shù)：

• +2 更改被批準(zhǔn)合并。只有 Go 維護者可以投 +2 票。
• +1 更改看起來不錯，但審查者在批準(zhǔn)之前要求進行較小的更改;或者他們不是維護者并且無法批準(zhǔn)它，但希望鼓勵批準(zhǔn)。
• -1 這個改動現(xiàn)在的狀態(tài)并不好，但可能是可以修復(fù)的。-1 投票將始終有注釋解釋為什么更改是不可接受的。
• -2 更改被維護者阻止，無法獲得批準(zhǔn)。同樣，將有一條評論解釋該決定。

“至少要有兩個維護者同意該更改，且其中至少一名維護者必須 +2 該更改。第二個維護者可能投了 Trust+1 的投票，這意味著更改看起來基本沒問題;但維護者還沒有完成 +2 投票所需的詳細審查。”

Cox 表示，他計劃在 GerritAccess 頁面上添加一些說明。即，“每個 CL 都需要來自一名 approver 的 code review (Code-Review+2) 和兩名 Google 員工的參與;要么是作為代碼上傳者，要么是作為審查者投票，至少是 Code-Review+1。要求多人確保不能從單個被盜帳戶單方面提交代碼。一旦審查獲得 Code-Review+2 和必要的 Google 參與，它就可以由任何 approver 提交。所有這些規(guī)則都由 Gerrit 服務(wù)器強制執(zhí)行?！?/p>

針對這一變更，Go 貢獻者、計算機科學(xué)家 Alberto Donizetti 則在郵件列表中表示，這一變化有效地限制了 Committer 群體，使其只限于谷歌員工。

當(dāng)被質(zhì)疑此次 Go 政策的改變是否使會得非 Google 維護者投出 +2 合并批準(zhǔn)票毫無意義時，Cox 進行了否認(rèn)并表示，“我們完全期望 CL 將繼續(xù)像今天一樣只接受非 Google 員工 Code-Review+2 審查”。并補充稱，預(yù)計在完成深入的 Code-Review+2 之后，因等待 Code-Review+1 的認(rèn)可而產(chǎn)生的任何延遲將是最小的。

此前，Go 官方博客曾介紹了他們應(yīng)對供應(yīng)鏈攻擊的緩解措施。TheRegister 指出，此次增加第二名谷歌員工的審查則擴大了現(xiàn)有的保障措施，谷歌此舉也許可以多提供一層保護措施，防止涉及員工叛變之類的威脅情況發(fā)生。

本文轉(zhuǎn)自O(shè)SCHINA

本文標(biāo)題：Go 限制 Committer 群體?每項更改都需 2 名谷歌員工審查

本文地址：https://www.oschina.net/news/190022/google-go-double-sign-off