LEDE 和 OpenWrt 分裂之爭

對於家用 WiFi 路由器和接入點來說，OpenWrt 項目可能是最廣為人知的 Linux 發行版；在 12 年以前，它產自現在有名的 Linksys WRT54G 路由器的源代碼。（2016 年）五月初，當一群 OpenWrt 核心開發者 宣布 他們將開始著手 OpenWrt 的一個副產品 （或者，可能算一個分支）叫 Linux 嵌入開發環境 （LEDE）時，OpenWrt 用戶社區陷入一片巨大的混亂中。為什麼產生分裂對公眾來說並不明朗，而且 LEDE 宣言驚到了一些其他 OpenWrt 開發者也暗示這團隊的內部矛盾。

LEDE 宣言被 Jo-Philipp Wich 於五月三日發往所有 OpenWrt 開發者列表和新 LEDE 開發者列表。它將 LEDE 描述為「OpenWrt 社區的一次重啟」 和 「OpenWrt 項目的一個副產品」 ，希望產生一個 「注重透明性、合作和權利分散」的 Linux 嵌入式開發社區。

給出的重啟的原因是 OpenWrt 遭受著長期以來存在且不能從內部解決的問題 —— 換句話說，關於內部處理方式和政策。例如，宣言稱，開發者的數目在不斷減少，卻沒有接納新開發者的方式（而且貌似沒有授權委託訪問給新開發者的方法）。宣言說到，項目的基礎設施不可靠（例如，去年伺服器掛掉在這個項目中也引發了相當多的矛盾），但是內部不合和單點錯誤阻止了修復它。內部和從這個項目到外面世界也存在著「交流、透明度和合作」的普遍缺失。最後，一些技術缺陷被引述：不充分的測試、缺乏常規維護，以及窘迫的穩固性與文檔。

該宣言繼續描述 LEDE 重啟將怎樣解決這些問題。所有交流頻道都會打開供公眾使用，決策將在項目範圍內的投票決出，合併政策將放寬等等。更詳細的說明可以在 LEDE 站點的規則頁找到。其他細節中，它說貢獻者將只有一個階級（也就是，沒有「核心開發者」這樣擁有額外權利的群體），簡單的少數服從多數投票作出決定，並且任何被這個項目管理的基礎設施必須有三個以上管理員賬戶。在 LEDE 郵件列表， Hauke Mehrtens 補充到，該項目將會努力把補丁投遞到上游項目 —— 這是過去 OpenWrt 被批判的一點，尤其是對 Linux 內核。

除了 Wich，這個宣言被 OpenWrt 貢獻者 John Crispin、 Daniel Golle、 Felix Fietkau、 Mehrtens、 Matthias Schiffer 和 Steven Barth 共同簽署，並以給其他有興趣參與的人訪問 LEDE 站點的邀請作為了宣言結尾。

回應和問題

有人可能會猜想 LEDE 組織者預期他們的宣言會有或積極或消極的反響。畢竟，細讀宣言中批判 OpenWrt 項目暗示了 LEDE 陣營發現有一些 OpenWrt 項目成員難以共事（例如，「單點錯誤」 或 「內部不和」阻止了基礎設施的修復）。

並且，確實，有很多消極回應。OpenWrt 創立者之一 Mike Baker 回應 了一些警告，反駁所有 LEDE 宣言中的結論並稱「像『重啟』這樣的詞語都是含糊不清的，且具有誤導性的，而且 LEDE 項目未能揭曉其真實本質。」與此同時，有人關閉了那些在 LEDE 宣言上署名的開發者的 @openwrt.org 郵件入口；當 Fietkau 提出反對， Baker 回復賬戶「暫時停用」是因為「還不確定 LEDE 能不能代表 OpenWrt。」 另一個 OpenWrt 核心成員 Imre Kaloz 寫到，他們現在所抱怨的 OpenWrt 的「大多數[破]事就是 LEDE 團隊弄出來的」。

但是大多數 OpenWrt 列表的回應對該宣言表示困惑。郵件列表成員不明確 LEDE 團隊是否將對 OpenWrt 繼續貢獻，或導致了這次分裂的架構和內部問題的確切本質是什麼。 Baker 的第一反應是對宣言中引述的那些問題缺乏公開討論表示難過：「我們意識到當前的 OpenWrt 項目遭受著許多的問題，」但「我們希望有機會去討論並嘗試著解決」它們。 Baker 作出結論：

我們想強調，我們確實希望能夠公開的討論，並解決掉手頭事情。我們的目標是與所有能夠且希望對 OpenWrt 作出貢獻的參與者共事，包括 LEDE 團隊。

除了有關新項目的初心的問題之外，一些郵件列表訂閱者提出了 LEDE 是否與 OpenWrt 有相同的使用場景定位，給新項目取一個聽起來更一般的名字的疑惑。此外，許多人，像 Roman Yeryomin，對為什麼這些問題需要 LEDE 團隊的離開（來解決）表示了疑惑，特別是，與此同時，LEDE 團隊由大部分活躍核心 OpenWrt 開發者構成。一些列表訂閱者，像 Michael Richardson，甚至不清楚誰還會繼續開發 OpenWrt。

澄清

LEDE 團隊嘗試著深入闡釋他們的境況。在 Fietkau 給 Baker 的回復中，他說在 OpenWrt 內部關於有目的地改變的討論會很快變得「有毒，」因此導致沒有進展。而且：

這些討論的要點在於那些掌握著基礎設施關鍵部分的人精力有限卻拒絕他人的加入和幫助，甚至是面對無法及時解決的重要問題時也是這樣。

這種像單點錯誤一樣的事已經持續了很多年了，沒有任何有意義的進展來解決它。

Wich 和 Fietkau 都沒有明顯指出具體的人，雖然在列表的其他人可能會想到這個基礎設施和 OpenWrt 的內部決策問題要歸咎於某些人。 Daniel Dickinson 陳述到：

我的印象是 Kaloz (至少) 以基礎設施為脅來保持控制，並且根本性的問題是 OpenWrt 是不民主的，而且忽視那些真正在 OpenWrt 工作的人想要的是什麼，無視他們的願望，因為他/他們把控著要害。

另一方面， Luka Perkov 指出 很多 OpemWrt 開發者想從 Subversion 轉移到 Git，但 Fietkau 卻阻止這種變化。

看起來是 OpenWrt 的管理結構並非如預期般發揮作用，其結果導致個人衝突爆發，而且由於沒有完好定義的流程，某些人能夠簡單的忽視或阻止提議的變化。明顯，這不是一個能長期持續的模式。

五月六日，Crispin 在一個新的帖子中寫給 OpenWrt 列表，嘗試著重構 LEDE 項目宣言。他說，這並不是意味著「敵對或分裂」行為，只是與結構失衡的 OpenWrt 做個清晰的劃分並以新的方式開始。問題在於「不要歸咎於一次單獨的事件、一個人或者一次口水戰」，他說，「我們想與過去自己造成的錯誤和多次作出的錯誤管理決定分開」。 Crispin 也承認宣言沒有把握好，說 LEDE 團隊 「弄糟了發起綱領。」

Crispin 的郵件似乎沒能使 Kaloz 滿意，她堅持認為 Crispin（作為發行經理）和 Fietkau（作為領頭開發者）可以輕易地在 OpenWrt 內部作出想要的改變。但是討論的下文後來變得沉寂；之後 LEDE 或者 OpenWrt 哪邊會發生什麼還有待觀察。

目的

對於那些想要探究 LEDE 所認為有問題的事情的更多細節的 OpenWrt 成員來說，有更多的信息來源可以為這個問題提供線索。在公眾宣言之前，LEDE 組織花了幾周談論他們的計劃，會議的 IRC 日誌現已發布。特別有趣的是，三月三十日的會議包含了這個項目目標的細節討論。

其中包括一些針對 OpenWrt 的基礎設施的抱怨，像項目的 Trac 工單追蹤器的缺點。它充斥著不完整的漏洞報告和「我也是」的評論，Wich 說，結果幾乎沒有貢獻者使用它。此外，他們也在 Github 上追蹤 bug，人們對這件事感到困惑，這使得工單應該在哪裡討論不明了。

這些 IRC 討論也定下了開發流程本身。LEDE 團隊想作出些改變，以使用會合併到主幹的階段開發分支為開端，與 OpenWrt 所使用的「直接提交到主幹」方式不同。該項目也將提供基於時間的發行版，並通過只發行已被成功測試的二進位模塊來鼓勵用戶測試，由社區而不是核心開發者在實際的硬體上進行測試。

最後，這些 IRC 討論也確定了 LEDE 團隊的目的不是用它的宣言嚇唬 OpenWrt。Crispin 提到 LEDE 首先是「半公開的」並漸漸做得更公開。 Wich 解釋說他希望 LEDE 是「中立的、專業的，並打開大門歡迎 OpenWrt 以便將來的合併」。不幸的是，前期發起工作並不是做得很好。

在一封郵件中， Fietkau 補充到 OpenWrt 核心開發者確實在任務中遇到瓶頸，像補丁複審和基礎設施維護這些事情讓他們完成不了其他工作，比如配置下載鏡像和改良構建系統。在 LEDE 宣言之後短短几天內，他說，團隊成功解決了鏡像和構建系統任務，而這些已被擱置多年。

我們在 LEDE 所做的事情很多是基於轉移到 Github 的去中心化軟體包開發經驗，並放棄了軟體包應如何被維護的許多控制。這樣最終有效減少了我們的工作量，而且我們有了很多更活躍的開發者。

我們真的希望為核心開發做一些類似的事，但是基於我們想作出更大改變的經驗，我們覺得在 OpenWrt 項目內做不到。

修復基礎設施也將收穫其他好處，他說，就比如改進了用於管理簽署發布版本的密碼的系統。團隊正在考慮在某些情況下非上游補丁的規則，像需要補丁的描述和為什麼沒有發送到上游的解釋。他也提到很多留下的 OpenWrt 開發者表示有興趣加入 LEDE，相關當事人正試圖弄清楚他們是否會重新合併該項目。

有人希望 LEDE 更為扁平的管理模式和更為透明的分工會在困擾 OpenWrt 的方面取得成功。解決最初的宣言中被詬病的溝通方面的問題會是最大的障礙。如果那個過程處理得好，那麼，未來 LEDE 和 OpenWrt 可能能夠求同存異並協作。否則，之後兩個團隊可能一起被迫發展到比以前擁有更少資源的方向，這也許不是開發者或用戶想看到的。

via: https://lwn.net/Articles/686767/

作者：Nathan Willis 譯者：XYenChi 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive