Documentation/translations/zh_TW/process/1.Intro.rst - linux - Git at Google

 .. SPDX-License-Identifier: GPL-2.0

 .. include:: ../disclaimer-zh_TW.rst

 :Original: :ref:`Documentation/process/1.Intro.rst <development_process_intro>`

 :Translator:

  時奎亮 Alex Shi <alex.shi@linux.alibaba.com>

 :校譯:

  吳想成 Wu XiangCheng <bobwxc@email.cn>
  胡皓文 Hu Haowen <src.res@email.cn>

 .. _tw_development_process_intro:

 引言
 ====

 內容提要
 --------

 本節的其餘部分涵蓋了內核開發的過程，以及開發人員及其僱主在這方面可能遇到的
 各種問題。有很多原因使內核代碼應被合併到正式的（「主線」）內核中，包括對用戶
 的自動可用性、多種形式的社區支持以及影響內核開發方向的能力。提供給Linux內核
 的代碼必須在與GPL兼容的許可證下可用。

 :ref:`tw_development_process` 介紹了開發過程、內核發布周期和合併窗口的機制。
 涵蓋了補丁開發、審查和合併周期中的各個階段。還有一些關於工具和郵件列表的討論？
 鼓勵希望開始內核開發的開發人員跟蹤並修復缺陷以作爲初步練習。


 :ref:`tw_development_early_stage` 包括項目的早期規劃，重點是儘快讓開發社區
 參與進來。

 :ref:`tw_development_coding` 是關於編程過程的；介紹了其他開發人員遇到的幾個
 陷阱。也涵蓋了對補丁的一些要求，並且介紹了一些工具，這些工具有助於確保內核
 補丁是正確的。

 :ref:`tw_development_posting` 描述發布補丁以供評審的過程。爲了讓開發社區能
 認真對待，補丁必須被正確格式化和描述，並且必須發送到正確的地方。遵循本節中的
 建議有助於確保您的工作能被較好地接納。

 :ref:`tw_development_followthrough` 介紹了發布補丁之後發生的事情；工作在這時
 還遠遠沒有完成。與審閱者一起工作是開發過程中的一個重要部分；本節提供了一些
 關於如何在這個重要階段避免問題的提示。當補丁被合併到主線中時，開發人員要注意
 不要假定任務已經完成。

 :ref:`tw_development_advancedtopics` 介紹了兩個「高級」主題：使用Git管理補丁
 和查看其他人發布的補丁。

 :ref:`tw_development_conclusion` 總結了有關內核開發的更多信息，附帶有相關資源
 連結。

 這個文檔是關於什麼的
 --------------------

 Linux內核有超過800萬行代碼，每個版本的貢獻者超過1000人，是現存最大、最活躍的
 免費軟體項目之一。從1991年開始，這個內核已經發展成爲一個最好的作業系統組件，
 運行在袖珍數位音樂播放器、桌上型電腦、現存最大的超級計算機以及所有類型的系統上。
 它是一種適用於幾乎任何情況的健壯、高效和可擴展的解決方案。

 隨著Linux的發展，希望參與其開發的開發人員（和公司）的數量也在增加。硬體供應商
 希望確保Linux能夠很好地支持他們的產品，使這些產品對Linux用戶具有吸引力。嵌入
 式系統供應商使用Linux作爲集成產品的組件，希望Linux能夠儘可能地勝任手頭的任務。
 分銷商和其他基於Linux的軟體供應商切實關心Linux內核的功能、性能和可靠性。最終
 用戶也常常希望修改Linux，使之能更好地滿足他們的需求。

 Linux最引人注目的特性之一是這些開發人員可以訪問它；任何具備必要技能的人都可以
 改進Linux並影響其開發方向。專有產品不能提供這種開放性，這是自由軟體的一個特點。
 如果有什麼不同的話，那就是內核比大多數其他自由軟體項目更開放。一個典型的三個
 月內核開發周期可以涉及1000多個開發人員，他們爲100多個不同的公司（或者根本不
 隸屬公司）工作。

 與內核開發社區合作並不是特別困難。但儘管如此，仍有許多潛在的貢獻者在嘗試做
 內核工作時遇到了困難。內核社區已經發展出自己獨特的操作方式，使其能夠在每天
 都要更改數千行代碼的環境中順利運行（並生成高質量的產品）。因此，Linux內核開發
 過程與專有的開發模式有很大的不同也就不足爲奇了。

 對於新開發人員來說，內核的開發過程可能會讓人感到奇怪和恐懼，但這背後有充分的
 理由和堅實的經驗。一個不了解內核社區工作方式的開發人員（或者更糟的是，他們
 試圖拋棄或規避之）會得到令人沮喪的體驗。開發社區在幫助那些試圖學習的人的同時，
 沒有時間幫助那些不願意傾聽或不關心開發過程的人。

 希望閱讀本文的人能夠避免這種令人沮喪的經歷。這些材料很長，但閱讀它們時所做的
 努力會在短時間內得到回報。開發社區總是需要能讓內核變更好的開發人員；下面的
 文字應該幫助您或爲您工作的人員加入我們的社區。

 致謝
 ----

 本文檔由Jonathan Corbet <corbet@lwn.net> 撰寫。以下人員的建議使之更爲完善：
 Johannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap,
 Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson,
 Andrew Morton, Andrew Price, Tsugikazu Shibata 和 Jochen Voß 。

 這項工作得到了Linux基金會的支持，特別感謝Amanda McPherson，他看到了這項工作
 的價值並將其變成現實。

 代碼進入主線的重要性
 --------------------

 有些公司和開發人員偶爾會想，爲什麼他們要費心學習如何與內核社區合作，並將代碼
 放入主線內核（「主線」是由Linus Torvalds維護的內核，Linux發行商將其用作基礎）。
 在短期內，貢獻代碼看起來像是一種可以避免的開銷；維護獨立代碼並直接支持用戶
 似乎更容易。事實上，保持代碼獨立（「樹外」）是在經濟上是錯誤的。

 爲了說明樹外代碼成本，下面給出內核開發過程的一些相關方面；本文稍後將更詳細地
 討論其中的大部分內容。請考慮：

 - 所有Linux用戶都可以使用合併到主線內核中的代碼。它將自動出現在所有啓用它的
   發行版上。無需驅動程序磁碟、額外下載，也不需要爲多個發行版的多個版本提供
   支持；這一切將方便所有開發人員和用戶。併入主線解決了大量的分發和支持問題。

 - 當內核開發人員努力維護一個穩定的用戶空間接口時，內核內部API處於不斷變化之中。
   不維持穩定的內部接口是一個慎重的設計決策；它允許在任何時候進行基本的改進，
   並產出更高質量的代碼。但該策略導致結果是，若要使用新的內核，任何樹外代碼都
   需要持續的維護。維護樹外代碼會需要大量的工作才能使代碼保持正常運行。

   相反，位於主線中的代碼不需要這樣做，因爲基本規則要求進行API更改的任何開發
   人員也必須修復由於該更改而破壞的任何代碼。因此，合併到主線中的代碼大大降低
   了維護成本。

 - 除此之外，內核中的代碼通常會被其他開發人員改進。您授權的用戶社區和客戶對您
   產品的改進可能會令人驚喜。

 - 內核代碼在合併到主線之前和之後都要經過審查。無論原始開發人員的技能有多強，
   這個審查過程總是能找到改進代碼的方法。審查經常發現嚴重的錯誤和安全問題。
   對於在封閉環境中開發的代碼尤其如此；這種代碼從外部開發人員的審查中獲益匪淺。
   樹外代碼是低質量代碼。

 - 參與開發過程是您影響內核開發方向的方式。旁觀者的抱怨會被聽到，但是活躍的
   開發人員有更強的聲音——並且能夠實現使內核更好地滿足其需求的更改。

 - 當單獨維護代碼時，總是存在第三方爲類似功能提供不同實現的可能性。如果發生
   這種情況，合併代碼將變得更加困難——甚至成爲不可能。之後，您將面臨以下令人
   不快的選擇：（1）無限期地維護樹外的非標準特性，或（2）放棄代碼並將用戶遷移
   到樹內版本。

 - 代碼的貢獻是使整個流程工作的根本。通過貢獻代碼，您可以向內核添加新功能，並
   提供其他內核開發人員使用的功能和示例。如果您已經爲Linux開發了代碼（或者正在
   考慮這樣做），那麼您顯然對這個平台的持續成功感興趣；貢獻代碼是確保成功的
   最好方法之一。

 上述所有理由都適用於任何樹外內核代碼，包括以專有的、僅二進位形式分發的代碼。
 然而，在考慮任何類型的純二進位內核代碼分布之前，還需要考慮其他因素。包括：

 - 圍繞專有內核模塊分發的法律問題其實較爲模糊；相當多的內核版權所有者認爲，
   大多數僅二進位的模塊是內核的派生產品，因此，它們的分發違反了GNU通用公共
   許可證（下面將詳細介紹）。本文作者不是律師，本文檔中的任何內容都不可能被
   視爲法律建議。封閉原始碼模塊的真實法律地位只能由法院決定。但不管怎樣，困擾
   這些模塊的不確定性仍然存在。

 - 二進位模塊大大增加了調試內核問題的難度，以至於大多數內核開發人員甚至都不會
   嘗試。因此，只分發二進位模塊將使您的用戶更難從社區獲得支持。

 - 對於僅二進位的模塊的發行者來說，支持也更加困難，他們必須爲他們希望支持的
   每個發行版和每個內核版本提供不同版本的模塊。爲了提供較爲全面的覆蓋範圍，
   可能需要一個模塊的幾十個構建，並且每次升級內核時，您的用戶都必須單獨升級
   這些模塊。

 - 上面提到的關於代碼評審的所有問題都更加存在於封閉原始碼中。由於該代碼根本
   不可得，因此社區無法對其進行審查，毫無疑問，它將存在嚴重問題。

 尤其是嵌入式系統的製造商，可能會傾向於忽視本節中所說的大部分內容；因爲他們
 相信自己正在商用一種使用凍結內核版本的獨立產品，在發布後不需要再進行開發。
 這個論點忽略了廣泛的代碼審查的價值以及允許用戶向產品添加功能的價值。但這些
 產品的商業壽命有限，之後必須發布新版本的產品。在這一點上，代碼在主線上並得到
 良好維護的供應商將能夠更好地占位，以使新產品快速上市。

 許可
 ----

 代碼是根據一些許可證提供給Linux內核的，但是所有代碼都必須與GNU通用公共許可
 證（GPLV2）的版本2兼容，該版本是覆蓋整個內核分發的許可證。在實踐中，這意味
 著所有代碼貢獻都由GPLv2（可選地，語言允許在更高版本的GPL下分發）或3子句BSD
 許可（New BSD License，譯者注）覆蓋。任何不包含在兼容許可證中的貢獻都不會
 被接受到內核中。

 貢獻給內核的代碼不需要（或請求）版權分配。合併到主線內核中的所有代碼都保留
 其原始所有權；因此，內核現在擁有數千個所有者。

 這種所有權結構也暗示著，任何改變內核許可的嘗試都註定會失敗。很少有實際情況
 可以獲得所有版權所有者的同意（或者從內核中刪除他們的代碼）。因此，尤其是在
 可預見的將來，許可證不大可能遷移到GPL的版本3。

 所有貢獻給內核的代碼都必須是合法的免費軟體。因此，不接受匿名（或化名）貢獻
 者的代碼。所有貢獻者都需要在他們的代碼上「sign off（簽發）」，聲明代碼可以
 在GPL下與內核一起分發。無法提供未被其所有者許可爲免費軟體的代碼，或可能爲
 內核造成版權相關問題的代碼（例如，由缺乏適當保護的反向工程工作派生的代碼）
 不能被接受。

 有關版權問題的提問在Linux開發郵件列表中很常見。這樣的問題通常會得到不少答案，
 但請記住，回答這些問題的人不是律師，不能提供法律諮詢。如果您有關於Linux原始碼
 的法律問題，沒有什麼可以代替諮詢了解這一領域的律師。依賴從技術郵件列表中獲得
 的答案是一件冒險的事情。
	.. SPDX-License-Identifier: GPL-2.0

	.. include:: ../disclaimer-zh_TW.rst

	:Original: :ref:`Documentation/process/1.Intro.rst <development_process_intro>`

	:Translator:

	時奎亮 Alex Shi <alex.shi@linux.alibaba.com>

	:校譯:

	吳想成 Wu XiangCheng <bobwxc@email.cn>
	胡皓文 Hu Haowen <src.res@email.cn>

	.. _tw_development_process_intro:

	引言
	====

	內容提要
	--------

	本節的其餘部分涵蓋了內核開發的過程，以及開發人員及其僱主在這方面可能遇到的
	各種問題。有很多原因使內核代碼應被合併到正式的（「主線」）內核中，包括對用戶
	的自動可用性、多種形式的社區支持以及影響內核開發方向的能力。提供給Linux內核
	的代碼必須在與GPL兼容的許可證下可用。

	:ref:`tw_development_process` 介紹了開發過程、內核發布周期和合併窗口的機制。
	涵蓋了補丁開發、審查和合併周期中的各個階段。還有一些關於工具和郵件列表的討論？
	鼓勵希望開始內核開發的開發人員跟蹤並修復缺陷以作爲初步練習。


	:ref:`tw_development_early_stage` 包括項目的早期規劃，重點是儘快讓開發社區
	參與進來。

	:ref:`tw_development_coding` 是關於編程過程的；介紹了其他開發人員遇到的幾個
	陷阱。也涵蓋了對補丁的一些要求，並且介紹了一些工具，這些工具有助於確保內核
	補丁是正確的。

	:ref:`tw_development_posting` 描述發布補丁以供評審的過程。爲了讓開發社區能
	認真對待，補丁必須被正確格式化和描述，並且必須發送到正確的地方。遵循本節中的
	建議有助於確保您的工作能被較好地接納。

	:ref:`tw_development_followthrough` 介紹了發布補丁之後發生的事情；工作在這時
	還遠遠沒有完成。與審閱者一起工作是開發過程中的一個重要部分；本節提供了一些
	關於如何在這個重要階段避免問題的提示。當補丁被合併到主線中時，開發人員要注意
	不要假定任務已經完成。

	:ref:`tw_development_advancedtopics` 介紹了兩個「高級」主題：使用Git管理補丁
	和查看其他人發布的補丁。

	:ref:`tw_development_conclusion` 總結了有關內核開發的更多信息，附帶有相關資源
	連結。

	這個文檔是關於什麼的
	--------------------

	Linux內核有超過800萬行代碼，每個版本的貢獻者超過1000人，是現存最大、最活躍的
	免費軟體項目之一。從1991年開始，這個內核已經發展成爲一個最好的作業系統組件，
	運行在袖珍數位音樂播放器、桌上型電腦、現存最大的超級計算機以及所有類型的系統上。
	它是一種適用於幾乎任何情況的健壯、高效和可擴展的解決方案。

	隨著Linux的發展，希望參與其開發的開發人員（和公司）的數量也在增加。硬體供應商
	希望確保Linux能夠很好地支持他們的產品，使這些產品對Linux用戶具有吸引力。嵌入
	式系統供應商使用Linux作爲集成產品的組件，希望Linux能夠儘可能地勝任手頭的任務。
	分銷商和其他基於Linux的軟體供應商切實關心Linux內核的功能、性能和可靠性。最終
	用戶也常常希望修改Linux，使之能更好地滿足他們的需求。

	Linux最引人注目的特性之一是這些開發人員可以訪問它；任何具備必要技能的人都可以
	改進Linux並影響其開發方向。專有產品不能提供這種開放性，這是自由軟體的一個特點。
	如果有什麼不同的話，那就是內核比大多數其他自由軟體項目更開放。一個典型的三個
	月內核開發周期可以涉及1000多個開發人員，他們爲100多個不同的公司（或者根本不
	隸屬公司）工作。

	與內核開發社區合作並不是特別困難。但儘管如此，仍有許多潛在的貢獻者在嘗試做
	內核工作時遇到了困難。內核社區已經發展出自己獨特的操作方式，使其能夠在每天
	都要更改數千行代碼的環境中順利運行（並生成高質量的產品）。因此，Linux內核開發
	過程與專有的開發模式有很大的不同也就不足爲奇了。

	對於新開發人員來說，內核的開發過程可能會讓人感到奇怪和恐懼，但這背後有充分的
	理由和堅實的經驗。一個不了解內核社區工作方式的開發人員（或者更糟的是，他們
	試圖拋棄或規避之）會得到令人沮喪的體驗。開發社區在幫助那些試圖學習的人的同時，
	沒有時間幫助那些不願意傾聽或不關心開發過程的人。

	希望閱讀本文的人能夠避免這種令人沮喪的經歷。這些材料很長，但閱讀它們時所做的
	努力會在短時間內得到回報。開發社區總是需要能讓內核變更好的開發人員；下面的
	文字應該幫助您或爲您工作的人員加入我們的社區。

	致謝
	----

	本文檔由Jonathan Corbet <corbet@lwn.net> 撰寫。以下人員的建議使之更爲完善：
	Johannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap,
	Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson,
	Andrew Morton, Andrew Price, Tsugikazu Shibata 和 Jochen Voß 。

	這項工作得到了Linux基金會的支持，特別感謝Amanda McPherson，他看到了這項工作
	的價值並將其變成現實。

	代碼進入主線的重要性
	--------------------

	有些公司和開發人員偶爾會想，爲什麼他們要費心學習如何與內核社區合作，並將代碼
	放入主線內核（「主線」是由Linus Torvalds維護的內核，Linux發行商將其用作基礎）。
	在短期內，貢獻代碼看起來像是一種可以避免的開銷；維護獨立代碼並直接支持用戶
	似乎更容易。事實上，保持代碼獨立（「樹外」）是在經濟上是錯誤的。

	爲了說明樹外代碼成本，下面給出內核開發過程的一些相關方面；本文稍後將更詳細地
	討論其中的大部分內容。請考慮：

	- 所有Linux用戶都可以使用合併到主線內核中的代碼。它將自動出現在所有啓用它的
	發行版上。無需驅動程序磁碟、額外下載，也不需要爲多個發行版的多個版本提供
	支持；這一切將方便所有開發人員和用戶。併入主線解決了大量的分發和支持問題。

	- 當內核開發人員努力維護一個穩定的用戶空間接口時，內核內部API處於不斷變化之中。
	不維持穩定的內部接口是一個慎重的設計決策；它允許在任何時候進行基本的改進，
	並產出更高質量的代碼。但該策略導致結果是，若要使用新的內核，任何樹外代碼都
	需要持續的維護。維護樹外代碼會需要大量的工作才能使代碼保持正常運行。

	相反，位於主線中的代碼不需要這樣做，因爲基本規則要求進行API更改的任何開發
	人員也必須修復由於該更改而破壞的任何代碼。因此，合併到主線中的代碼大大降低
	了維護成本。

	- 除此之外，內核中的代碼通常會被其他開發人員改進。您授權的用戶社區和客戶對您
	產品的改進可能會令人驚喜。

	- 內核代碼在合併到主線之前和之後都要經過審查。無論原始開發人員的技能有多強，
	這個審查過程總是能找到改進代碼的方法。審查經常發現嚴重的錯誤和安全問題。
	對於在封閉環境中開發的代碼尤其如此；這種代碼從外部開發人員的審查中獲益匪淺。
	樹外代碼是低質量代碼。

	- 參與開發過程是您影響內核開發方向的方式。旁觀者的抱怨會被聽到，但是活躍的
	開發人員有更強的聲音——並且能夠實現使內核更好地滿足其需求的更改。

	- 當單獨維護代碼時，總是存在第三方爲類似功能提供不同實現的可能性。如果發生
	這種情況，合併代碼將變得更加困難——甚至成爲不可能。之後，您將面臨以下令人
	不快的選擇：（1）無限期地維護樹外的非標準特性，或（2）放棄代碼並將用戶遷移
	到樹內版本。

	- 代碼的貢獻是使整個流程工作的根本。通過貢獻代碼，您可以向內核添加新功能，並
	提供其他內核開發人員使用的功能和示例。如果您已經爲Linux開發了代碼（或者正在
	考慮這樣做），那麼您顯然對這個平台的持續成功感興趣；貢獻代碼是確保成功的
	最好方法之一。

	上述所有理由都適用於任何樹外內核代碼，包括以專有的、僅二進位形式分發的代碼。
	然而，在考慮任何類型的純二進位內核代碼分布之前，還需要考慮其他因素。包括：

	- 圍繞專有內核模塊分發的法律問題其實較爲模糊；相當多的內核版權所有者認爲，
	大多數僅二進位的模塊是內核的派生產品，因此，它們的分發違反了GNU通用公共
	許可證（下面將詳細介紹）。本文作者不是律師，本文檔中的任何內容都不可能被
	視爲法律建議。封閉原始碼模塊的真實法律地位只能由法院決定。但不管怎樣，困擾
	這些模塊的不確定性仍然存在。

	- 二進位模塊大大增加了調試內核問題的難度，以至於大多數內核開發人員甚至都不會
	嘗試。因此，只分發二進位模塊將使您的用戶更難從社區獲得支持。

	- 對於僅二進位的模塊的發行者來說，支持也更加困難，他們必須爲他們希望支持的
	每個發行版和每個內核版本提供不同版本的模塊。爲了提供較爲全面的覆蓋範圍，
	可能需要一個模塊的幾十個構建，並且每次升級內核時，您的用戶都必須單獨升級
	這些模塊。

	- 上面提到的關於代碼評審的所有問題都更加存在於封閉原始碼中。由於該代碼根本
	不可得，因此社區無法對其進行審查，毫無疑問，它將存在嚴重問題。

	尤其是嵌入式系統的製造商，可能會傾向於忽視本節中所說的大部分內容；因爲他們
	相信自己正在商用一種使用凍結內核版本的獨立產品，在發布後不需要再進行開發。
	這個論點忽略了廣泛的代碼審查的價值以及允許用戶向產品添加功能的價值。但這些
	產品的商業壽命有限，之後必須發布新版本的產品。在這一點上，代碼在主線上並得到
	良好維護的供應商將能夠更好地占位，以使新產品快速上市。

	許可
	----

	代碼是根據一些許可證提供給Linux內核的，但是所有代碼都必須與GNU通用公共許可
	證（GPLV2）的版本2兼容，該版本是覆蓋整個內核分發的許可證。在實踐中，這意味
	著所有代碼貢獻都由GPLv2（可選地，語言允許在更高版本的GPL下分發）或3子句BSD
	許可（New BSD License，譯者注）覆蓋。任何不包含在兼容許可證中的貢獻都不會
	被接受到內核中。

	貢獻給內核的代碼不需要（或請求）版權分配。合併到主線內核中的所有代碼都保留
	其原始所有權；因此，內核現在擁有數千個所有者。

	這種所有權結構也暗示著，任何改變內核許可的嘗試都註定會失敗。很少有實際情況
	可以獲得所有版權所有者的同意（或者從內核中刪除他們的代碼）。因此，尤其是在
	可預見的將來，許可證不大可能遷移到GPL的版本3。

	所有貢獻給內核的代碼都必須是合法的免費軟體。因此，不接受匿名（或化名）貢獻
	者的代碼。所有貢獻者都需要在他們的代碼上「sign off（簽發）」，聲明代碼可以
	在GPL下與內核一起分發。無法提供未被其所有者許可爲免費軟體的代碼，或可能爲
	內核造成版權相關問題的代碼（例如，由缺乏適當保護的反向工程工作派生的代碼）
	不能被接受。

	有關版權問題的提問在Linux開發郵件列表中很常見。這樣的問題通常會得到不少答案，
	但請記住，回答這些問題的人不是律師，不能提供法律諮詢。如果您有關於Linux原始碼
	的法律問題，沒有什麼可以代替諮詢了解這一領域的律師。依賴從技術郵件列表中獲得
	的答案是一件冒險的事情。