0001 .. SPDX-License-Identifier: GPL-2.0
0002
0003 .. include:: ../disclaimer-zh_TW.rst
0004
0005 :Original: :ref:`Documentation/process/1.Intro.rst <development_process_intro>`
0006
0007 :Translator:
0008
0009 時奎亮 Alex Shi <alex.shi@linux.alibaba.com>
0010
0011 :校譯:
0012
0013 吳想成 Wu XiangCheng <bobwxc@email.cn>
0014 胡皓文 Hu Haowen <src.res@email.cn>
0015
0016 .. _tw_development_process_intro:
0017
0018 引言
0019 ====
0020
0021 內容提要
0022 --------
0023
0024 本節的其餘部分涵蓋了內核開發的過程，以及開發人員及其僱主在這方面可能遇到的
0025 各種問題。有很多原因使內核代碼應被合併到正式的（「主線」）內核中，包括對用戶
0026 的自動可用性、多種形式的社區支持以及影響內核開發方向的能力。提供給Linux內核
0027 的代碼必須在與GPL兼容的許可證下可用。
0028
0029 :ref:`tw_development_process` 介紹了開發過程、內核發布周期和合併窗口的機制。
0030 涵蓋了補丁開發、審查和合併周期中的各個階段。還有一些關於工具和郵件列表的討論？
0031 鼓勵希望開始內核開發的開發人員跟蹤並修復缺陷以作爲初步練習。
0032
0033
0034 :ref:`tw_development_early_stage` 包括項目的早期規劃，重點是儘快讓開發社區
0035 參與進來。
0036
0037 :ref:`tw_development_coding` 是關於編程過程的；介紹了其他開發人員遇到的幾個
0038 陷阱。也涵蓋了對補丁的一些要求，並且介紹了一些工具，這些工具有助於確保內核
0039 補丁是正確的。
0040
0041 :ref:`tw_development_posting` 描述發布補丁以供評審的過程。爲了讓開發社區能
0042 認真對待，補丁必須被正確格式化和描述，並且必須發送到正確的地方。遵循本節中的
0043 建議有助於確保您的工作能被較好地接納。
0044
0045 :ref:`tw_development_followthrough` 介紹了發布補丁之後發生的事情；工作在這時
0046 還遠遠沒有完成。與審閱者一起工作是開發過程中的一個重要部分；本節提供了一些
0047 關於如何在這個重要階段避免問題的提示。當補丁被合併到主線中時，開發人員要注意
0048 不要假定任務已經完成。
0049
0050 :ref:`tw_development_advancedtopics` 介紹了兩個「高級」主題：使用Git管理補丁
0051 和查看其他人發布的補丁。
0052
0053 :ref:`tw_development_conclusion` 總結了有關內核開發的更多信息，附帶有相關資源
0054 連結。
0055
0056 這個文檔是關於什麼的
0057 --------------------
0058
0059 Linux內核有超過800萬行代碼，每個版本的貢獻者超過1000人，是現存最大、最活躍的
0060 免費軟體項目之一。從1991年開始，這個內核已經發展成爲一個最好的作業系統組件，
0061 運行在袖珍數位音樂播放器、桌上型電腦、現存最大的超級計算機以及所有類型的系統上。
0062 它是一種適用於幾乎任何情況的健壯、高效和可擴展的解決方案。
0063
0064 隨著Linux的發展，希望參與其開發的開發人員（和公司）的數量也在增加。硬體供應商
0065 希望確保Linux能夠很好地支持他們的產品，使這些產品對Linux用戶具有吸引力。嵌入
0066 式系統供應商使用Linux作爲集成產品的組件，希望Linux能夠儘可能地勝任手頭的任務。
0067 分銷商和其他基於Linux的軟體供應商切實關心Linux內核的功能、性能和可靠性。最終
0068 用戶也常常希望修改Linux，使之能更好地滿足他們的需求。
0069
0070 Linux最引人注目的特性之一是這些開發人員可以訪問它；任何具備必要技能的人都可以
0071 改進Linux並影響其開發方向。專有產品不能提供這種開放性，這是自由軟體的一個特點。
0072 如果有什麼不同的話，那就是內核比大多數其他自由軟體項目更開放。一個典型的三個
0073 月內核開發周期可以涉及1000多個開發人員，他們爲100多個不同的公司（或者根本不
0074 隸屬公司）工作。
0075
0076 與內核開發社區合作並不是特別困難。但儘管如此，仍有許多潛在的貢獻者在嘗試做
0077 內核工作時遇到了困難。內核社區已經發展出自己獨特的操作方式，使其能夠在每天
0078 都要更改數千行代碼的環境中順利運行（並生成高質量的產品）。因此，Linux內核開發
0079 過程與專有的開發模式有很大的不同也就不足爲奇了。
0080
0081 對於新開發人員來說，內核的開發過程可能會讓人感到奇怪和恐懼，但這背後有充分的
0082 理由和堅實的經驗。一個不了解內核社區工作方式的開發人員（或者更糟的是，他們
0083 試圖拋棄或規避之）會得到令人沮喪的體驗。開發社區在幫助那些試圖學習的人的同時，
0084 沒有時間幫助那些不願意傾聽或不關心開發過程的人。
0085
0086 希望閱讀本文的人能夠避免這種令人沮喪的經歷。這些材料很長，但閱讀它們時所做的
0087 努力會在短時間內得到回報。開發社區總是需要能讓內核變更好的開發人員；下面的
0088 文字應該幫助您或爲您工作的人員加入我們的社區。
0089
0090 致謝
0091 ----
0092
0093 本文檔由Jonathan Corbet <corbet@lwn.net> 撰寫。以下人員的建議使之更爲完善：
0094 Johannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap,
0095 Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson,
0096 Andrew Morton, Andrew Price, Tsugikazu Shibata 和 Jochen Voß 。
0097
0098 這項工作得到了Linux基金會的支持，特別感謝Amanda McPherson，他看到了這項工作
0099 的價值並將其變成現實。
0100
0101 代碼進入主線的重要性
0102 --------------------
0103
0104 有些公司和開發人員偶爾會想，爲什麼他們要費心學習如何與內核社區合作，並將代碼
0105 放入主線內核（「主線」是由Linus Torvalds維護的內核，Linux發行商將其用作基礎）。
0106 在短期內，貢獻代碼看起來像是一種可以避免的開銷；維護獨立代碼並直接支持用戶
0107 似乎更容易。事實上，保持代碼獨立（「樹外」）是在經濟上是錯誤的。
0108
0109 爲了說明樹外代碼成本，下面給出內核開發過程的一些相關方面；本文稍後將更詳細地
0110 討論其中的大部分內容。請考慮：
0111
0112 - 所有Linux用戶都可以使用合併到主線內核中的代碼。它將自動出現在所有啓用它的
0113 發行版上。無需驅動程序磁碟、額外下載，也不需要爲多個發行版的多個版本提供
0114 支持；這一切將方便所有開發人員和用戶。併入主線解決了大量的分發和支持問題。
0115
0116 - 當內核開發人員努力維護一個穩定的用戶空間接口時，內核內部API處於不斷變化之中。
0117 不維持穩定的內部接口是一個慎重的設計決策；它允許在任何時候進行基本的改進，
0118 並產出更高質量的代碼。但該策略導致結果是，若要使用新的內核，任何樹外代碼都
0119 需要持續的維護。維護樹外代碼會需要大量的工作才能使代碼保持正常運行。
0120
0121 相反，位於主線中的代碼不需要這樣做，因爲基本規則要求進行API更改的任何開發
0122 人員也必須修復由於該更改而破壞的任何代碼。因此，合併到主線中的代碼大大降低
0123 了維護成本。
0124
0125 - 除此之外，內核中的代碼通常會被其他開發人員改進。您授權的用戶社區和客戶對您
0126 產品的改進可能會令人驚喜。
0127
0128 - 內核代碼在合併到主線之前和之後都要經過審查。無論原始開發人員的技能有多強，
0129 這個審查過程總是能找到改進代碼的方法。審查經常發現嚴重的錯誤和安全問題。
0130 對於在封閉環境中開發的代碼尤其如此；這種代碼從外部開發人員的審查中獲益匪淺。
0131 樹外代碼是低質量代碼。
0132
0133 - 參與開發過程是您影響內核開發方向的方式。旁觀者的抱怨會被聽到，但是活躍的
0134 開發人員有更強的聲音——並且能夠實現使內核更好地滿足其需求的更改。
0135
0136 - 當單獨維護代碼時，總是存在第三方爲類似功能提供不同實現的可能性。如果發生
0137 這種情況，合併代碼將變得更加困難——甚至成爲不可能。之後，您將面臨以下令人
0138 不快的選擇：（1）無限期地維護樹外的非標準特性，或（2）放棄代碼並將用戶遷移
0139 到樹內版本。
0140
0141 - 代碼的貢獻是使整個流程工作的根本。通過貢獻代碼，您可以向內核添加新功能，並
0142 提供其他內核開發人員使用的功能和示例。如果您已經爲Linux開發了代碼（或者正在
0143 考慮這樣做），那麼您顯然對這個平台的持續成功感興趣；貢獻代碼是確保成功的
0144 最好方法之一。
0145
0146 上述所有理由都適用於任何樹外內核代碼，包括以專有的、僅二進位形式分發的代碼。
0147 然而，在考慮任何類型的純二進位內核代碼分布之前，還需要考慮其他因素。包括：
0148
0149 - 圍繞專有內核模塊分發的法律問題其實較爲模糊；相當多的內核版權所有者認爲，
0150 大多數僅二進位的模塊是內核的派生產品，因此，它們的分發違反了GNU通用公共
0151 許可證（下面將詳細介紹）。本文作者不是律師，本文檔中的任何內容都不可能被
0152 視爲法律建議。封閉原始碼模塊的真實法律地位只能由法院決定。但不管怎樣，困擾
0153 這些模塊的不確定性仍然存在。
0154
0155 - 二進位模塊大大增加了調試內核問題的難度，以至於大多數內核開發人員甚至都不會
0156 嘗試。因此，只分發二進位模塊將使您的用戶更難從社區獲得支持。
0157
0158 - 對於僅二進位的模塊的發行者來說，支持也更加困難，他們必須爲他們希望支持的
0159 每個發行版和每個內核版本提供不同版本的模塊。爲了提供較爲全面的覆蓋範圍，
0160 可能需要一個模塊的幾十個構建，並且每次升級內核時，您的用戶都必須單獨升級
0161 這些模塊。
0162
0163 - 上面提到的關於代碼評審的所有問題都更加存在於封閉原始碼中。由於該代碼根本
0164 不可得，因此社區無法對其進行審查，毫無疑問，它將存在嚴重問題。
0165
0166 尤其是嵌入式系統的製造商，可能會傾向於忽視本節中所說的大部分內容；因爲他們
0167 相信自己正在商用一種使用凍結內核版本的獨立產品，在發布後不需要再進行開發。
0168 這個論點忽略了廣泛的代碼審查的價值以及允許用戶向產品添加功能的價值。但這些
0169 產品的商業壽命有限，之後必須發布新版本的產品。在這一點上，代碼在主線上並得到
0170 良好維護的供應商將能夠更好地占位，以使新產品快速上市。
0171
0172 許可
0173 ----
0174
0175 代碼是根據一些許可證提供給Linux內核的，但是所有代碼都必須與GNU通用公共許可
0176 證（GPLV2）的版本2兼容，該版本是覆蓋整個內核分發的許可證。在實踐中，這意味
0177 著所有代碼貢獻都由GPLv2（可選地，語言允許在更高版本的GPL下分發）或3子句BSD
0178 許可（New BSD License，譯者注）覆蓋。任何不包含在兼容許可證中的貢獻都不會
0179 被接受到內核中。
0180
0181 貢獻給內核的代碼不需要（或請求）版權分配。合併到主線內核中的所有代碼都保留
0182 其原始所有權；因此，內核現在擁有數千個所有者。
0183
0184 這種所有權結構也暗示著，任何改變內核許可的嘗試都註定會失敗。很少有實際情況
0185 可以獲得所有版權所有者的同意（或者從內核中刪除他們的代碼）。因此，尤其是在
0186 可預見的將來，許可證不大可能遷移到GPL的版本3。
0187
0188 所有貢獻給內核的代碼都必須是合法的免費軟體。因此，不接受匿名（或化名）貢獻
0189 者的代碼。所有貢獻者都需要在他們的代碼上「sign off（簽發）」，聲明代碼可以
0190 在GPL下與內核一起分發。無法提供未被其所有者許可爲免費軟體的代碼，或可能爲
0191 內核造成版權相關問題的代碼（例如，由缺乏適當保護的反向工程工作派生的代碼）
0192 不能被接受。
0193
0194 有關版權問題的提問在Linux開發郵件列表中很常見。這樣的問題通常會得到不少答案，
0195 但請記住，回答這些問題的人不是律師，不能提供法律諮詢。如果您有關於Linux原始碼
0196 的法律問題，沒有什麼可以代替諮詢了解這一領域的律師。依賴從技術郵件列表中獲得
0197 的答案是一件冒險的事情。
0198
0199
