Documentation/translations/zh_TW/process/3.Early-stage.rst

   1 .. SPDX-License-Identifier: GPL-2.0
   2
   3 .. include:: ../disclaimer-zh_TW.rst
   4
   5 :Original: :ref:`Documentation/process/3.Early-stage.rst <development_early_stage>`
   6
   7 :Translator:
   8
   9  時奎亮 Alex Shi <alex.shi@linux.alibaba.com>
  10
  11 :校譯:
  12
  13  吳想成 Wu XiangCheng <bobwxc@email.cn>
  14  胡皓文 Hu Haowen <src.res@email.cn>
  15
  16 .. _tw_development_early_stage:
  17
  18 早期規劃
  19 ========
  20
  21 當考慮一個Linux內核開發項目時，很可能會直接跳進去開始編碼。然而，與任何重要
  22 的項目一樣，許多成功的基礎最好是在第一行代碼編寫之前就打下。在早期計劃和
  23 溝通中花費一些時間可以在之後節省更多的時間。
  24
  25 搞清問題
  26 --------
  27
  28 與任何工程項目一樣，成功的內核改善從清晰描述要解決的問題開始。在某些情況
  29 下，這個步驟很容易：例如當某個特定硬體需要驅動程序時。不過，在其他情況下，
  30 很容易將實際問題與建議的解決方案混在一起，這可能會導致麻煩。
  31
  32 舉個例子：幾年前，Linux音頻的開發人員尋求一種方法來運行應用程式，而不會因
  33 系統延遲過大而導致退出或其他問題。他們得到的解決方案是一個連接到Linux安全
  34 模塊（LSM）框架中的內核模塊；這個模塊可以配置爲允許特定的應用程式訪問實時
  35 調度程序。這個模塊被實現並發到linux-kernel郵件列表，在那裡它立即遇到了麻煩。
  36
  37 對於音頻開發人員來說，這個安全模塊足以解決他們當前的問題。但是，對於更廣泛的
  38 內核社區來說，這被視爲對LSM框架的濫用（LSM框架並不打算授予他們原本不具備的
  39 進程特權），並對系統穩定性造成風險。他們首選的解決方案包括短期的通過rlimit
  40 機制進行實時調度訪問，以及長期的減少延遲的工作。
  41
  42 然而，音頻社區無法超越他們實施的特定解決方案來看問題；他們不願意接受替代方案。
  43 由此產生的分歧使這些開發人員對整個內核開發過程感到失望；其中一個開發人員返回
  44 到audio列表並發布了以下內容：
  45
  46         有很多非常好的Linux內核開發人員，但他們往往會被一羣傲慢的傻瓜所壓倒。
  47         試圖向這些人傳達用戶需求是浪費時間。他們太「聰明」了，根本聽不到少數
  48         人的話。
  49
  50 （http://lwn.net/articles/131776/）
  51
  52 實際情況卻是不同的；與特定模塊相比，內核開發人員更關心系統穩定性、長期維護
  53 以及找到問題的正確解決方案。這個故事的寓意是把重點放在問題上——而不是具體的
  54 解決方案上——並在開始編寫代碼之前與開發社區討論這個問題。
  55
  56 因此，在考慮一個內核開發項目時，我們應該得到一組簡短問題的答案：
  57
  58  - 需要解決的問題究竟是什麼？
  59
  60  - 受此問題影響的用戶有哪些？解決方案應該解決哪些使用案例？
  61
  62  - 內核現在爲何沒能解決這個問題？
  63
  64 只有這樣，才能開始考慮可能的解決方案。
  65
  66
  67 早期討論
  68 --------
  69
  70 在計劃內核開發項目時，在開始實施之前與社區進行討論是很有意義的。早期溝通可以
  71 通過多種方式節省時間和麻煩：
  72
  73  - 很可能問題是由內核以您不理解的方式解決的。Linux內核很大，具有許多不明顯
  74    的特性和功能。並不是所有的內核功能都像人們所希望的那樣有文檔記錄，而且很
  75    容易遺漏一些東西。某作者發布了一個完整的驅動程序，重複了一個其不
  76    知道的現有驅動程序。重新發明現有輪子的代碼不僅浪費，而且不會被接受到主線
  77    內核中。
  78
  79  - 建議的解決方案中可能有一些要素不適合併入主線。在編寫代碼之前，最好先了解
  80    這樣的問題。
  81
  82  - 其他開發人員完全有可能考慮過這個問題；他們可能有更好的解決方案的想法，並且
  83    可能願意幫助創建這個解決方案。
  84
  85 在內核開發社區的多年經驗給了我們一個明確的教訓：閉門設計和開發的內核代碼總是
  86 有一些問題，這些問題只有在代碼發布到社區中時才會被發現。有時這些問題很嚴重，
  87 需要數月或數年的努力才能使代碼達到內核社區的標準。例如：
  88
  89  - 設計並實現了單處理器系統的DeviceScape網絡棧。只有使其適合於多處理器系統，
  90    才能將其合併到主線中。在代碼中修改鎖等等是一項困難的任務；因此，這段代碼
  91    （現在稱爲mac80211）的合併被推遲了一年多。
  92
  93  - Reiser4文件系統包含許多功能，核心內核開發人員認爲這些功能應該在虛擬文件
  94    系統層中實現。它還包括一些特性，這些特性在不將系統暴露於用戶引起的死鎖的
  95    情況下是不容易實現的。這些問題過遲發現——以及拒絕處理其中一些問題——已經
  96    導致Reiser4置身主線內核之外。
  97
  98  - Apparmor安全模塊以被認爲不安全和不可靠的方式使用內部虛擬文件系統數據結構。
  99    這種擔心（包括其他）使Apparmor多年來無法進入主線。
 100
 101 在這些情況下，與內核開發人員的早期討論，可以避免大量的痛苦和額外的工作。
 102
 103 找誰交流？
 104 ----------
 105
 106 當開發人員決定公開他們的計劃時，下一個問題是：我們從哪裡開始？答案是找到正確
 107 的郵件列表和正確的維護者。對於郵件列表，最好的方法是在維護者(MAINTAINERS)文件
 108 中查找要發布的相關位置。如果有一個合適的子系統列表，那麼其上發布通常比在
 109 linux-kernel上發布更可取；您更有可能接觸到在相關子系統中具有專業知識的開發
 110 人員，並且環境可能具支持性。
 111
 112 找到維護人員可能會有點困難。同樣，維護者文件是開始的地方。但是，該文件往往不
 113 是最新的，並且並非所有子系統都在那裡顯示。實際上，維護者文件中列出的人員可能
 114 不是當前實際擔任該角色的人員。因此，當對聯繫誰有疑問時，一個有用的技巧是使用
 115 git（尤其是「git-log」）查看感興趣的子系統中當前活動的用戶。看看誰在寫補丁、
 116 誰會在這些補丁上加上Signed-off-by行簽名（如有）。這些人將是幫助新開發項目的
 117 最佳人選。
 118
 119 找到合適的維護者有時是非常具有挑戰性的，以至於內核開發人員添加了一個腳本來
 120 簡化這個過程：
 121
 122 ::
 123
 124         .../scripts/get_maintainer.pl
 125
 126 當給定「-f」選項時，此腳本將返回指定文件或目錄的當前維護者。如果在命令行上
 127 給出了一個補丁，它將列出可能接收補丁副本的維護人員。有許多選項可以調節
 128 get_maintainer.pl搜索維護者的嚴格程度；請小心使用更激進的選項，因爲最終結果
 129 可能會包括對您正在修改的代碼沒有真正興趣的開發人員。
 130
 131 如果所有其他方法都失敗了，那麼與Andrew Morton交流是跟蹤特定代碼段維護人員
 132 的一種有效方法。
 133
 134 何時郵寄？
 135 ----------
 136
 137 如果可能的話，在早期階段發布你的計劃只會更有幫助。描述正在解決的問題以及已經
 138 制定的關於如何實施的任何計劃。您可以提供的任何信息都可以幫助開發社區爲項目
 139 提供有用的輸入。
 140
 141 在這個階段可能發生的一件令人沮喪的事情不是得到反對意見，而是很少或根本沒有
 142 反饋。令人傷心的事實是：（1）內核開發人員往往很忙；（2）不缺少有宏偉計劃但
 143 代碼（甚至代碼設想）很少的人去支持他們；（3）沒有人有義務審查或評論別人發表
 144 的想法。除此之外，高層級的設計常常隱藏著一些問題，這些問題只有在有人真正嘗試
 145 實現這些設計時才會被發現；因此，內核開發人員寧願看到代碼。
 146
 147 如果發布請求評論（RFC）並沒得到什麼有用的評論，不要以爲這意味著無人對此項目
 148 有興趣，同時你也不能假設你的想法沒有問題。在這種情況下，最好的做法是繼續進
 149 行，把你的進展隨時通知社區。
 150
 151 獲得官方認可
 152 -----------------------
 153
 154 如果您的工作是在公司環境中完成的，就像大多數Linux內核工作一樣；顯然，在您將
 155 公司的計劃或代碼發布到公共郵件列表之前，必須獲得有適當權利經理的許可。發布
 156 不確定是否兼容GPL的代碼尤其會帶來問題；公司的管理層和法律人員越早能夠就發布
 157 內核開發項目達成一致，對參與的每個人都越好。
 158
 159 一些讀者可能會認爲他們的核心工作是爲了支持還沒有正式承認存在的產品。將僱主
 160 的計劃公布在公共郵件列表上可能不是一個可行的選擇。在這種情況下，有必要考慮
 161 保密是否真的是必要的；通常不需要把開發計劃關在門內。
 162
 163 的確，有些情況下一家公司在開發過程的早期無法合法地披露其計劃。擁有經驗豐富
 164 的內核開發人員的公司可能選擇以開環的方式進行開發，前提是他們以後能夠避免
 165 嚴重的集成問題。對於沒有這種內部專業知識的公司，最好的選擇往往是聘請外部
 166 開發者根據保密協議審查計劃。Linux基金會運行了一個NDA程序，旨在幫助解決這種
 167 情況；更多信息參見：
 168
 169     http://www.linuxfoundation.org/nda/
 170
 171 這種審查通常足以避免以後出現嚴重問題，而無需公開披露項目。
 172