LWN：Red Hat 如何在內(nèi)核開發(fā)流程中使用 GitLab！

關(guān)注了就能看到更多這么棒的文章哦～

How Red Hat uses GitLab for kernel development

By Jonathan Corbet
October 1, 2021
LPC
DeepL assisted translation
https://lwn.net/Articles/871237/

自由軟件的開發(fā)世界中有許多社區(qū)已經(jīng)開始擁抱 Git forges 工具了（如 GitHub、GitLab 或 sourcehut 等）。但內(nèi)核社區(qū)卻還沒有。這里有許多原因，但其中一個(gè)經(jīng)常被人們聽到的理由是，這些 Git forge 工具在內(nèi)核項(xiàng)目這么大的規(guī)模下根本無法很好地完成工作。在 2021 年 Linux Plumbers 會(huì)議期間的一次內(nèi)核峰會(huì)討論中，Donald Zickus 和 Parit Bhargava 希望向大家展示 Red Hat 如何將 GitLab 很好地用在支持內(nèi)核團(tuán)隊(duì)的開發(fā)工作上。他們說，這些
forge 工具不僅可以用于內(nèi)核開發(fā)，而且轉(zhuǎn)移過去之后可以帶來許多好處。

The transition

Zickus 開始演講，他說 Red Hat 在去年將其內(nèi)核團(tuán)隊(duì)從 "一個(gè)基于 Patchwork 的舊服務(wù)" 過渡到 GitLab。在這個(gè)改動(dòng)之前，該團(tuán)隊(duì)采用的是一個(gè)相當(dāng)傳統(tǒng)的、基于電子郵件的工作流程，隨著 patch 數(shù)量的增加，這個(gè)工作流程變得更難管理。紅帽公司在 patch review 以及獲得相關(guān)人員的確認(rèn)方面有很多嚴(yán)格的規(guī)定，而在 patch 不斷闖關(guān)的過程中，越來越難以跟蹤清楚這些 patch 是否已經(jīng)完成了相關(guān)的流程，這里需要許多人工的判斷工作。reviewer 不知道他們應(yīng)該看哪些 patch，而持續(xù)集成（CI）系統(tǒng)則是固化關(guān)聯(lián)起來的（was bolted on）。

是時(shí)候做出改變了，所以該公司轉(zhuǎn)向了 GitLab。

Bhargava 簡要介紹了 Lab 工具，這是 GitLab 中許多功能的一個(gè)可以從命令行調(diào)用的接口。也許具有諷刺意味的是，這個(gè)工具其實(shí)是托管在 GitHub 上的。他說很多開發(fā)者都喜歡命令行界面。

一般來說，內(nèi)核維護(hù)者往往都有自己的一套腳本。每個(gè)維護(hù)者的工具都各不相同。有些維護(hù)者會(huì)檢測某些類型的錯(cuò)誤，而另一些維護(hù)者則不會(huì)。GitLab 可以對于 action 來運(yùn)行腳本，這樣一來就可以取代大部分這種定制的檢測了，能確保每個(gè) patch 得到處理都是有一致性的，并都正確帶有相關(guān)的簽名，包括（這里顯然是強(qiáng)制性的）Bugzilla ID 等。patch 如果在某方面出現(xiàn)問題，就會(huì)被標(biāo)記為需要注意（attention）。

Bhargava 說，電子郵件使得人們很容易對可以對 patch 發(fā)表意見。但對于維護(hù)者來說，要從大量的信息中篩選出有價(jià)值的，就不那么容易了。GitLab 能夠?qū)?comment 和 reply 都按 thread 來區(qū)分開，全部都是按照 merge request 來組織起來的，這樣就使得這一過程更加容易。所有這些都會(huì)跟最終那個(gè) " big fat 'approve' button" 關(guān)聯(lián)在一起，共同決定是否允許合并。他說，目前為止他沒有再看到有開發(fā)者使用基于電子郵件的批準(zhǔn)。

upstream 內(nèi)核會(huì)使用 MAINTAINERS 文件來決定應(yīng)該由誰來 review 某個(gè)特定的 patch，這對代碼貢獻(xiàn)者來說又是一個(gè)需要記住的步驟。在 Red Hat 內(nèi)部，這個(gè)過程現(xiàn)在已經(jīng)自動(dòng)化了，當(dāng)一個(gè) merge request 被生成時(shí)，維護(hù)者和 reviewer 會(huì)根據(jù) owners.yaml 文件來自動(dòng)分配。review 有兩類，分別取決于是否需要 reviewer 的批準(zhǔn)。有興趣的開發(fā)者可以通過進(jìn)行注冊來獲得某個(gè)領(lǐng)域的相關(guān)改動(dòng)的通知。

以前，CI 是被添加到基于電子郵件的流程中，跟 patch 的生成過程是分開的。沒有人強(qiáng)制要求使用 CI。在新系統(tǒng)中，CI 被直接整合進(jìn)來。他說，雖然大多數(shù)維護(hù)者對 CI 系統(tǒng)并沒有太多熱情，但其實(shí)不應(yīng)該是這樣。CI 系統(tǒng)為內(nèi)核穩(wěn)定性提供了很多幫助。在為整個(gè)內(nèi)核做的一些 CI 測試中，開發(fā)人員甚至不知道當(dāng)前有測試正在進(jìn)行。GitLab 使 CI 測試變得更加明確，可見性強(qiáng)。

接下來 Zickus 接著介紹，他說與 GitLab 合作的經(jīng)歷并不是完全順利的，他們在一段時(shí)間內(nèi)，不斷發(fā)現(xiàn)各種問題。GitLab 與他們合作解決了這些問題，其中主要是關(guān)于 API 和工具的。Red Hat 也有一個(gè)專門的小組在處理 GitLab 未能解決的問題。兩家公司之間存在的是 "戰(zhàn)略伙伴關(guān)系"。

當(dāng)然，還有一些未解決的問題，包括如何管理信任鏈（chain of trust）：針對內(nèi)核的 pull request 都需要進(jìn)行簽名。對 pull request 進(jìn)行更好的記錄也會(huì)有幫助。不過，這里最大的擔(dān)憂可能還是 GitLab 可能會(huì)成為一個(gè)單點(diǎn)故障源。如果該公司被那些對 Red Hat 及其目標(biāo)有敵意的人收購了怎么辦？在這種情況下，從系統(tǒng)中提取所有必要的數(shù)據(jù)還是比較容易的。Git tree 已經(jīng)被 mirror 到其他存儲(chǔ)了。他們現(xiàn)在有一個(gè)腳本，可以從 GitLab 中提取所有的評論，并把它們轉(zhuǎn)到一個(gè) public-inbox 中。

Prarit 在結(jié)束準(zhǔn)備好的演講時(shí)說，現(xiàn)在還不能 100% 地確定 GitLab 是否是接下來最好的方向，盡管 Red Hat 目前對它的投入相當(dāng)深入。但他說，Git forge 的方法是值得嘗試的。在進(jìn)行過渡時(shí)，會(huì)有很多擔(dān)心，但事實(shí)證明那些并不會(huì)成為真正的問題。

Discussion

Greg Kroah-Hartman 在討論開始時(shí)（有點(diǎn)開玩笑地）祝賀演講者將 Gerrit 的所有功能整合到 GitLab 中。但是接下來他問道，使用這樣管理方式的 patch 數(shù)量到底有多少？Zickus 回答說，他們每三個(gè)月會(huì)為 RHEL update 來管理 15000 -16000 個(gè) patch。Bhargava 說，當(dāng)他們兩年前坐下來研究 forge 工具時(shí)，Gerrit 并沒有他們所需要的許多功能，也許后來 Gerrit 已經(jīng)變得更好了。

Ted Ts'o 說，他最擔(dān)心的問題是子系統(tǒng)之間的協(xié)作。如果關(guān)于某一個(gè)子系統(tǒng)的所有信息都被孤立出來存放在 GitLab 中，那么其他子系統(tǒng)的開發(fā)者就會(huì)多了不少麻煩。尤其是相關(guān)的討論內(nèi)容，比如說 Gerrit 的 comment 只在 Gerrit 里面存在。內(nèi)核社區(qū)可以考慮在 kernel.org 托管一個(gè) GitLab 實(shí)例，但這樣一來，有些 patch 的 comment 會(huì)出現(xiàn)在這里，而另一些則會(huì)出現(xiàn)在 mailing list 中。開發(fā)者將不得不在兩個(gè)地方同時(shí)搜索來獲得完整信息。他說，除非電子郵件能夠在開發(fā)過程中保持頭等公民的地位，否則很難看到一個(gè)可行的過渡方案。

Zickus 回答說，Red Hat 現(xiàn)在正在運(yùn)行一個(gè) email bridge，用來緩解開發(fā)人員的過渡階段碰到的麻煩。不過并不打算作為一個(gè)長期的解決方案保留下來。

Konstantin Ryabitsev 說，他對在 kernel.org 上托管一個(gè) forge 服務(wù)的方案不感興趣。在那里托管過 Bugzilla 服務(wù)，體驗(yàn)就并不好，基本上已經(jīng)被遺棄了，但他還不得不繼續(xù)清理那里積累的垃圾郵件。一旦一個(gè)工具被添加進(jìn)來開始用起來，就幾乎不可能進(jìn)行刪除，因?yàn)榭偸遣豢杀苊獾赜袔讉€(gè)人會(huì)依賴它。所以它就不得不永遠(yuǎn)被維護(hù)著。

不過，一個(gè)更大的問題是與茁壯性（robustness）。如果 kernel.org 突然無法訪問了，那么內(nèi)核開發(fā)仍可以繼續(xù)。臨時(shí)中斷一下雖然有點(diǎn)不方便，但不是一個(gè)真正的大問題。但是，如果增加一個(gè)中心 forge 服務(wù)，就有可能造成這樣一種情況，即它發(fā)生故障的時(shí)候任何工作都無法完成。他說，想象一下這樣一種情況：有一個(gè)影響數(shù)十億設(shè)備的 zero-day 漏洞，而攻擊者想阻止它被修補(bǔ)。這樣一來，攻擊像這類中心 forge 服務(wù)之類的關(guān)鍵基礎(chǔ)設(shè)施對他來說就是一個(gè)好主意了。如果這種情況下的處理方式是 "退回到電子郵件方案"，那么什么都沒有真正得到解決。

Zickus 說 GitLab 被復(fù)制（replicated）并存儲(chǔ)在谷歌云上，對此 Ryabitsev 回應(yīng)說谷歌云在俄羅斯和中國等部分地區(qū)是無法使用的。他說，依賴一個(gè)大型的云服務(wù)商并不是一個(gè)好的解決方案；另一方面，self-hosting 也帶來了自己特有的一些擴(kuò)展性以及費(fèi)用問題。Zickus 說，Red Hat 在中國有一個(gè)龐大的測試團(tuán)隊(duì)，GitLab 在那里運(yùn)行良好。不過，如果情況發(fā)生變化的話，那確實(shí)會(huì)是比較麻煩的。

Ryabitsev 說他并不反對將子系統(tǒng)轉(zhuǎn)到 forge 服務(wù)，只要確保它不會(huì)成為 "一個(gè)無人關(guān)注的討論位置"。目前，如果基礎(chǔ)設(shè)施不可用了，那些 "歷史記錄" 仍然存在于 lore.kernel.org 等網(wǎng)站上。Zickus 說，將相關(guān)討論都自動(dòng)轉(zhuǎn)發(fā)到 public-inbox 確實(shí)可以解決一部分問題。他隨后總結(jié)了這段討論，認(rèn)為沒有人真正反對使用這個(gè)工具，人們只是在擔(dān)心如何保存那里發(fā)生的討論。

時(shí)間不夠了，Ts'o 認(rèn)為這次會(huì)議并不代表討論結(jié)束。像 GitLab 這樣的 forge 服務(wù)指出了我們的未來方向，像自動(dòng) CI 測試這樣的功能確實(shí)是個(gè)好主意。

這次演講的視頻可以在 YouTube 上看到。

全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。

長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～