docs/zh_TW: add translations for zh_TW/process

下面的文檔介紹了Linux內核原始碼的許可證（GPLv2）、如何在原始碼樹中正確標記

單個文件的許可證、以及指向完整許可證文本的連結。

TODOList:

* Documentation/translations/zh_TW/process/license-rules.rst

Documentation/translations/zh_TW/process/license-rules.rst

用戶文檔

--------

開發人員做出貢獻。與任何大型社區一樣，知道如何完成任務將使得更改合併的過程

變得更加容易。

.. toctree::

   :maxdepth: 2

   process/index

TODOList:

* process/index

* dev-tools/index

* doc-guide/index

* kernel-hacking/index

.. 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/3.Early-stage.rst <development_early_stage>`

:Translator:

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

:校譯:

 吳想成 Wu XiangCheng <bobwxc@email.cn>

 胡皓文 Hu Haowen <src.res@email.cn>

.. _tw_development_early_stage:

早期規劃

========

當考慮一個Linux內核開發項目時，很可能會直接跳進去開始編碼。然而，與任何重要

的項目一樣，許多成功的基礎最好是在第一行代碼編寫之前就打下。在早期計劃和

溝通中花費一些時間可以在之後節省更多的時間。

搞清問題

--------

與任何工程項目一樣，成功的內核改善從清晰描述要解決的問題開始。在某些情況

下，這個步驟很容易：例如當某個特定硬體需要驅動程序時。不過，在其他情況下，

很容易將實際問題與建議的解決方案混在一起，這可能會導致麻煩。

舉個例子：幾年前，Linux音頻的開發人員尋求一種方法來運行應用程式，而不會因

系統延遲過大而導致退出或其他問題。他們得到的解決方案是一個連接到Linux安全

模塊（LSM）框架中的內核模塊；這個模塊可以配置爲允許特定的應用程式訪問實時

調度程序。這個模塊被實現並發到linux-kernel郵件列表，在那裡它立即遇到了麻煩。

對於音頻開發人員來說，這個安全模塊足以解決他們當前的問題。但是，對於更廣泛的

內核社區來說，這被視爲對LSM框架的濫用（LSM框架並不打算授予他們原本不具備的

進程特權），並對系統穩定性造成風險。他們首選的解決方案包括短期的通過rlimit

機制進行實時調度訪問，以及長期的減少延遲的工作。

然而，音頻社區無法超越他們實施的特定解決方案來看問題；他們不願意接受替代方案。

由此產生的分歧使這些開發人員對整個內核開發過程感到失望；其中一個開發人員返回

到audio列表並發布了以下內容：

	有很多非常好的Linux內核開發人員，但他們往往會被一羣傲慢的傻瓜所壓倒。

	試圖向這些人傳達用戶需求是浪費時間。他們太「聰明」了，根本聽不到少數

	人的話。

（http://lwn.net/articles/131776/）

實際情況卻是不同的；與特定模塊相比，內核開發人員更關心系統穩定性、長期維護

以及找到問題的正確解決方案。這個故事的寓意是把重點放在問題上——而不是具體的

解決方案上——並在開始編寫代碼之前與開發社區討論這個問題。

因此，在考慮一個內核開發項目時，我們應該得到一組簡短問題的答案：

 - 需要解決的問題究竟是什麼？

 - 受此問題影響的用戶有哪些？解決方案應該解決哪些使用案例？

 - 內核現在爲何沒能解決這個問題？

只有這樣，才能開始考慮可能的解決方案。

早期討論

--------

在計劃內核開發項目時，在開始實施之前與社區進行討論是很有意義的。早期溝通可以

通過多種方式節省時間和麻煩：

 - 很可能問題是由內核以您不理解的方式解決的。Linux內核很大，具有許多不明顯

   的特性和功能。並不是所有的內核功能都像人們所希望的那樣有文檔記錄，而且很

   容易遺漏一些東西。某作者發布了一個完整的驅動程序，重複了一個其不

   知道的現有驅動程序。重新發明現有輪子的代碼不僅浪費，而且不會被接受到主線

   內核中。

 - 建議的解決方案中可能有一些要素不適合併入主線。在編寫代碼之前，最好先了解

   這樣的問題。

 - 其他開發人員完全有可能考慮過這個問題；他們可能有更好的解決方案的想法，並且

   可能願意幫助創建這個解決方案。

在內核開發社區的多年經驗給了我們一個明確的教訓：閉門設計和開發的內核代碼總是

有一些問題，這些問題只有在代碼發布到社區中時才會被發現。有時這些問題很嚴重，

需要數月或數年的努力才能使代碼達到內核社區的標準。例如：

 - 設計並實現了單處理器系統的DeviceScape網絡棧。只有使其適合於多處理器系統，

   才能將其合併到主線中。在代碼中修改鎖等等是一項困難的任務；因此，這段代碼

   （現在稱爲mac80211）的合併被推遲了一年多。

 - Reiser4文件系統包含許多功能，核心內核開發人員認爲這些功能應該在虛擬文件

   系統層中實現。它還包括一些特性，這些特性在不將系統暴露於用戶引起的死鎖的

   情況下是不容易實現的。這些問題過遲發現——以及拒絕處理其中一些問題——已經

   導致Reiser4置身主線內核之外。

 - Apparmor安全模塊以被認爲不安全和不可靠的方式使用內部虛擬文件系統數據結構。

   這種擔心（包括其他）使Apparmor多年來無法進入主線。

在這些情況下，與內核開發人員的早期討論，可以避免大量的痛苦和額外的工作。

找誰交流？

----------

當開發人員決定公開他們的計劃時，下一個問題是：我們從哪裡開始？答案是找到正確

的郵件列表和正確的維護者。對於郵件列表，最好的方法是在維護者(MAINTAINERS)文件

中查找要發布的相關位置。如果有一個合適的子系統列表，那麼其上發布通常比在

linux-kernel上發布更可取；您更有可能接觸到在相關子系統中具有專業知識的開發

人員，並且環境可能具支持性。

找到維護人員可能會有點困難。同樣，維護者文件是開始的地方。但是，該文件往往不

是最新的，並且並非所有子系統都在那裡顯示。實際上，維護者文件中列出的人員可能

不是當前實際擔任該角色的人員。因此，當對聯繫誰有疑問時，一個有用的技巧是使用

git（尤其是「git-log」）查看感興趣的子系統中當前活動的用戶。看看誰在寫補丁、

誰會在這些補丁上加上Signed-off-by行簽名（如有）。這些人將是幫助新開發項目的

最佳人選。

找到合適的維護者有時是非常具有挑戰性的，以至於內核開發人員添加了一個腳本來

簡化這個過程：

::

	.../scripts/get_maintainer.pl

當給定「-f」選項時，此腳本將返回指定文件或目錄的當前維護者。如果在命令行上

給出了一個補丁，它將列出可能接收補丁副本的維護人員。有許多選項可以調節

get_maintainer.pl搜索維護者的嚴格程度；請小心使用更激進的選項，因爲最終結果

可能會包括對您正在修改的代碼沒有真正興趣的開發人員。

如果所有其他方法都失敗了，那麼與Andrew Morton交流是跟蹤特定代碼段維護人員

的一種有效方法。

何時郵寄？

----------

如果可能的話，在早期階段發布你的計劃只會更有幫助。描述正在解決的問題以及已經

制定的關於如何實施的任何計劃。您可以提供的任何信息都可以幫助開發社區爲項目

提供有用的輸入。

在這個階段可能發生的一件令人沮喪的事情不是得到反對意見，而是很少或根本沒有

反饋。令人傷心的事實是：（1）內核開發人員往往很忙；（2）不缺少有宏偉計劃但

代碼（甚至代碼設想）很少的人去支持他們；（3）沒有人有義務審查或評論別人發表

的想法。除此之外，高層級的設計常常隱藏著一些問題，這些問題只有在有人真正嘗試

實現這些設計時才會被發現；因此，內核開發人員寧願看到代碼。

如果發布請求評論（RFC）並沒得到什麼有用的評論，不要以爲這意味著無人對此項目

有興趣，同時你也不能假設你的想法沒有問題。在這種情況下，最好的做法是繼續進

行，把你的進展隨時通知社區。

獲得官方認可

-----------------------

如果您的工作是在公司環境中完成的，就像大多數Linux內核工作一樣；顯然，在您將

公司的計劃或代碼發布到公共郵件列表之前，必須獲得有適當權利經理的許可。發布

不確定是否兼容GPL的代碼尤其會帶來問題；公司的管理層和法律人員越早能夠就發布

內核開發項目達成一致，對參與的每個人都越好。

一些讀者可能會認爲他們的核心工作是爲了支持還沒有正式承認存在的產品。將僱主

的計劃公布在公共郵件列表上可能不是一個可行的選擇。在這種情況下，有必要考慮

保密是否真的是必要的；通常不需要把開發計劃關在門內。

的確，有些情況下一家公司在開發過程的早期無法合法地披露其計劃。擁有經驗豐富

的內核開發人員的公司可能選擇以開環的方式進行開發，前提是他們以後能夠避免

嚴重的集成問題。對於沒有這種內部專業知識的公司，最好的選擇往往是聘請外部

開發者根據保密協議審查計劃。Linux基金會運行了一個NDA程序，旨在幫助解決這種

情況；更多信息參見：

    http://www.linuxfoundation.org/nda/

這種審查通常足以避免以後出現嚴重問題，而無需公開披露項目。