隨著 Linus Torvalds 的正式決策，Linux 6.13 版本合併了從核心中刪除 ReiserFS 檔案系統的補丁，將移除 32.8k 行程式碼，由此宣告 ReiserFS 正式退出歷史舞臺。沒想到，一個檔案系統剛終結，Linux 核心中的另一大檔案系統 bcachefs 又出了“亂子”，
bcachefs 首席開發者 Kent Overstreet 於近日釋出了一篇名為《Trouble in the kernel》的長文，透露 Linus 不接受他在 Linux 6.13 中提交的 Bcachefs 拉取請求，給出的理由是“CoC（行為準則）委員會存在未解決的問題”。
這一擱置，Overstreet 表示，這導致 Bcachefs 的未來變得不確定，而且很多事情看起來也不太樂觀。
但是他自己也覺得委屈，甚至在長文中列舉了不少例子，劍指 Linux 文化和工作方式存在一些問題，其中有些人還用別人的職業生涯以此作為威脅，迫使他們遵守規定……
一時的口舌之快，導致所有的合併請求被拒
bcachefs 是一種高效能的 Linux 檔案系統，設計用於提供高效的資料儲存與訪問能力，該檔案系統的設計初衷是與 ZFS 或 Btrfs 等現代檔案系統競爭，同時在速度和效能方面與 ext4 和 XFS 相媲美。它是由資深開發者 Kent Oberstreet 建立而成，在 Linux 6.7 核心中獲得支援。
仔細想想，Linux 6.7 釋出至今也還未到一年的時間，為何現如今 Kent Oberstreet 的合併請求會被 Linus 拒絕？
一切或許與他自己的“火爆”脾氣有關。
要知道，在 bcachefs 被正式合併到 Linux 核心之前， Kent Oberstreet 就曾與 Linux 核心開發者們就 “Bcachefs 檔案系統驅動程式” 在郵件列表展開了激烈討論，當時氣氛也有些劍拔弩張，好在後來 Linus 親自 Review 程式碼，並就相關情況發表自己的看法之後，才得以平息這一爭論。
然而，Linus 幫得了一次，幫不了每一次。就在今年 9 月，Kent Oberstreet 在一封主題為“bcachefs：請勿使用 PF_MEMALLOC_NORECLAIM”郵件列表中，怒氣衝衝地對 SUSE 的開發者 Michal Hocko 說道：
我們已經在另一個郵件執行緒中討論過這個問題。我必須說，我不認為返回 NULL 會使有問題的程式碼變得更好。為什麼？因為我們可以預期，有問題的 NOFAIL 使用者不會有一個錯誤檢查路徑。即使是有效的 NOFAIL 使用者也不會有，因為他們知道他們沒有不同於無限重試的恢復路徑。
你在問我要討論和理由的連結，對吧？我還在等那個連結呢。
我不是你的助手，不會被指派去搜索傳統檔案。如果你需要，自己去找。
無論如何，如果你讀了那封郵件，甚至嘗試理解裡面寫了什麼，而不是立即大喊大叫地回應，你就會注意到我在這裡提出了實際的論點。你可以自由地不同意這些論點，並提出你的論點。你卻選擇了……
……
> 是的，夠了這種瘋狂。
所以我認為你不能這樣做。再次……
Michal，如果你認為讓程序崩潰是可以接受的錯誤處理替代方案，那麼你就不應該編寫核心程式碼。
你一直在強烈地提出一個接一個的糟糕想法，這對那些真正關心編寫可靠軟體的人是一種侮辱。
你反對的是核心程式設計的基本原則。
檢查一下你的腦子吧。帶著這些垃圾滾蛋。
作為一名擔任 Linux 核心工程師已有 15 年多的資深維護者，Kent Overstreet 這種說話的方式讓很多人不滿，甚至這番言論被視為“人身攻擊”。
這封郵件引起了 Linux 核心 CoC 委員會 Shuah Khan 的注意，隨即要求 Overstreet 不要使用此類過激的語言，並遵守 Linux 社群行為準則。
沒過多久，Overstreet 回應說他已經與 Michal 私下協商好了，並把二人討論的細節抄送給 CoC 委員會。
然而，Shuah Khan 並沒有就此罷休，而是要求 Overstreet 針對這一言論公開道歉並保證以後禁止這種不可接受的行為。
Overstreet：拒絕公開道歉
對此，Overstreet 在博文中稱，這只是一次技術討論的失控，當時的情況是：
-
檔案系統領域的開發者最初非常反對 PF_MEMALLOC_NORECLAIM，但在進一步討論實際影響，以及檢視實際的 GFP_NOFAIL 使用和錯誤處理路徑後，他們似乎開始轉變態度。
然而，推動回滾的 mm 維護者並不買賬，他說這件事已經在幕後討論中決定了，並且不願意進行技術討論；當被要求提供這些討論的理據時，他提供了一份決定的電子表格，但沒有解釋原因。
當 mm 維護者表示他希望直接殺死那些錯誤使用 GFP_NOFAIL 的程序，而不是讓它們返回到缺失的錯誤處理路徑時，Overstreet 在氣急之下，才會曝出上述那些髒話，他寫道——“我不認為這些言論是惡意的，也不是針對個人的。包括我在內的許多人都陷入了技術爭論，過於專注於贏得勝利和推進我們的觀點，以至於我們忘記退一步來看看更廣闊的前景。確實會發生！畢竟，我們都是凡人。”
Overstreet 透露，他事後也收到了包括 Linus 給他發的郵件，大意就是：“相信我，你不想因為是個混蛋而出名，你最好給那位道歉。”
Overstreet 還提到，其實他之前和 Linus 之間也有過拉鋸式討論（比如程式碼提交時的爭論）。回看今年 10 月，Linus 在合併了實驗性 Bcachefs 檔案系統的最新一輪修復時，直接犀利地回覆道：
我真的受夠了，Kent。
這些是昨晚的提交時間。
在你又開始抱怨你是如何修復 Bug 之前，讓我提醒你一下你在 big-endian 機器上的構建失敗，因為你的補丁在你的樹之外沒有經過任何測試。
那是上週的事了，我有種強烈的感覺，這次經歷完全沒有讓我們學到任何東西。
我已經拉取了這個，但我在列表中搜索了幾條提交資訊，卻一無所獲（好吧，我找到了你的拉取請求，其中明顯提到了提交資訊的第一行）。
我正在認真考慮停止從你那裡拉取，因為我根本看不到你在改進你的模型。 如果你想擁有一棵實驗樹，你完全可以在主線核心之外擁有一棵。 我已經告訴過你了，但似乎沒有什麼能讓你真正理解。
我曾希望並期待 bcachefs 被主線化能真正幫助開發。但事實並非如此。基本上你仍然是唯一的開發者，沒有任何跡象表明這一點會改變，而且你似乎覺得在下一個 RC 版本釋出的前一天把別人從未見過的未經測試的東西發給我就可以了。
你是個聰明人。 我覺得我給你的提示已經夠多了。 你為什麼不坐下來好好想想呢？讓我們把話說清楚：你在這裡正好有兩個選擇：
(a) 和別人玩得更好（和 Linux 社群其他人合作）
(b) 帶著你的玩具回家（從 Linux 主線中剝離）
這就是選擇。
Linus
Overstreet 表示，“但我想特別說明：我們雖然偶爾會互相較勁，但那是因為我們都非常在乎自己的工作，只是對問題的看法不太一樣。這種爭論其實是有益的，因為我們總能找到共同點，找到前進的辦法，也從中學到東西——儘管這些討論偶爾有點戲劇化。”
不過，他也收到了一些提到“行為準則委員會”（CoC）的郵件，並稱「聽起來就像提到了某種“魔鬼”。CoC 的處理方式是，只要有匿名投訴被注意到，他們就會要求某人公開道歉，否則就會採取措施」：
我拒絕公開道歉，原因有幾個：
-
這是一個長期積累的問題，已經影響到多個團隊和專案，應該認真討論這個問題；
-
更廣泛的來說，我認為 CoC 委員會本身存在一些問題；
-
最重要的是，這種事情本該私下解決。
Linus 在六年前反思自己後，上線了 CoC
那麼，CoC 到底是什麼？
這可以從 Linux 之父 Linus Torvalds 在六年前的一次休假談起。
一直以來，Linus Torvalds 的火爆脾氣在整個社群都是出了名的，無論是核心維護者的程式碼寫不好，還是企業在解決問題上有所拖延、亦或是看一些程式語言不順眼，他都是無所忌憚地直接開懟。
直到 2018 年，Linus 因為自己弄錯了一次核心維護者峰會的日期而在社群引發了大量的討論，這次錯誤與爭議也讓他開始反省自己。當時的他表示，想要向被他言語傷害的人道歉。他稱自己需要離開一段時間，需要幫助來更恰當地理解一個人的情緒和反應。
經此次事情後不久，Linux 社群就上線了一個行為準則（Code of Conduct，https://www.kernel.org/doc/html/latest/process/code-of-conduct.html），旨在營造一個開放而熱情的環境，為專案和社群的每位參與者創造免受騷擾的體驗，無論其年齡、體型、殘疾、種族、性別特徵、性別認同和性別表達、經驗水平、教育、社會經濟地位、國籍、外表、種族、宗教，或性認同和性取向。
同時，該準則背後還有一個委員會負責監督與執行。
開發者怒斥 CoC 委員會
此次 Linus 拒絕 Overstreet 所提交的合併請求，只要是因為 CoC 委員會在背後推動。不過，CoC 委員會透過 Shuah 對此情況的處理也讓包括 Kent 在內的許多 Linux 核心維護人員對這種高壓態勢感到失望，同時 CoC 的執行也受到了質疑。
Overstreet 在長文中分享了自己之前的經歷，他表示：
在 Plumbers 大會上，一位知名的 CoC 成員兼核心穩定版維護者和我談了一次話。在這個過程中，他試圖讓我遵循 CoC 的“流程”，並提到：
1.社群形象很重要；
2.多次暗示“如果我不在了會很可惜”。
他的“形象”說辭，聽起來更像是“要讓公司滿意”。我提到這一點是因為在會上，另一位高層維護者也提過類似話：“Linux 現在是為大公司服務的。”
但我不能認同。Linux 的起步與大公司無關，我 25 年前從郵件列表上學習做工程師，而科技公司只是過客，Linux 會超越它們的生命週期。我們的責任是服務於社群和使用者，維繫並保護這個備受依賴的工程文化。
更重要的是，不用說，威脅某人的職業生涯來讓他們遵守規定並不是一個好方法。
那位 CoC 成員在會上隨意辱罵檔案系統社群的每個成員，說他們都是混蛋。可這些人其實是英雄：
-
Matthew Wilcox 是個傳奇人物，他完成了 folios 的開發，這大大優化了 4K 頁面開銷。現代 NVMe 裝置的效能需求讓這種工作變得必不可少，否則 Linux 可能已經失去在檔案系統領域的 relevancy。
-
Ted T’so 保證了 Linux 使用者擁有一個可靠的檔案系統。他負責了許多幕後維護工作，比如 e2fsck 的可靠性，是社群裡的支柱。
-
Wedson Almeida Filho 為推動 Rust 檔案系統介面做了巨大努力。
在檔案系統社群工作雖然壓力大，但大家關係很近，爭論也只限技術討論。
如今我看到的卻是，一些領導者的行為根本沒起到帶頭作用。
過於強硬的處理方式，會讓人不願參與討論，甚至滋生一種敷衍文化——因為這樣更“安全”，避免捲入激烈爭論。
…
社群不是可以隨意替換的零件。我們應當互相關心，而不是簡單地“踢掉麻煩製造者”。我編寫程式碼是因為熱愛和享受這片社群氛圍，而不是為了大公司的利益。
最終，Overstreet 的反駁以及拒絕公開道歉行為，根據行為準則委員會的建議，Linux 基金會技術顧問委員會決定在 Linux 6.13 開發週期內拒絕所有來自 他的合併請求。
針對此舉，有開發者評價道：
-
我不得不站在 CoC 團隊這邊。Kent 你在 LKML 上的行為簡直令人無法接受。在技術爭論方面，你可能是對的，也可能不是，但這不是這裡的問題。你一次又一次與 Linus 的討論也是如此，當他希望你遵循與其他人相同的程式時，你完全無視他所說的話，你只是爭辯說你的方式更好，你的 FS 比 BTreeFS 更好，這不構成爭論。這對你來說可能很難，但你真的需要改進你的行為，否則 bcachefs 本身可能會成為附帶損害。
-
我確信與開源社群的一些成員打交道確實很辛苦，而且是一項不值得羨慕的任務。我確信小封地無處不在。Rust 的人似乎也遇到了類似的問題。不過，我想，我為這個專案做出貢獻的原因之一是，我認為它最有可能成為下一代預設檔案系統。這是非常需要的。如果它脫離核心，這實際上不會發生，而且傳統上脫離核心的檔案系統並沒有真正做得很好。我想除非您要讓一個大型發行版將其用作預設檔案系統，那可能只有 Ubuntu 或 RH（也許是 Fedora）。據我所知，即使是 Suse 也無法讓 ReisierFS 得到更廣泛的採用。最好的做法是讓一些壓力從這件事中消退。祝一切順利
對此，你怎麼看？
參考：
https://news.itsfoss.com/linux-kernel-bcachefs/
https://www.patreon.com/posts/trouble-in-116412665
– EOF –
