Documentation/translations/zh_TW/process/stable-kernel-rules.rst

   1 .. SPDX-License-Identifier: GPL-2.0
   2
   3 .. _tw_stable_kernel_rules:
   4
   5 .. include:: ../disclaimer-zh_TW.rst
   6
   7 :Original: :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
   8
   9 如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
  10 交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
  11 譯存在問題，請聯繫中文版維護者::
  12
  13         中文版維護者： 鍾宇  TripleX Chung <xxx.phy@gmail.com>
  14         中文版翻譯者： 鍾宇  TripleX Chung <xxx.phy@gmail.com>
  15         中文版校譯者：
  16             - 李陽  Li Yang <leoyang.li@nxp.com>
  17             - Kangkai Yin <e12051@motorola.com>
  18             - 胡皓文 Hu Haowen <src.res@email.cn>
  19
  20 所有你想知道的事情 - 關於linux穩定版發布
  21 ========================================
  22
  23 關於Linux 2.6穩定版發布，所有你想知道的事情。
  24
  25 關於哪些類型的補丁可以被接收進入穩定版代碼樹，哪些不可以的規則：
  26 ----------------------------------------------------------------
  27
  28   - 必須是顯而易見的正確，並且經過測試的。
  29   - 連同上下文，不能大於100行。
  30   - 必須只修正一件事情。
  31   - 必須修正了一個給大家帶來麻煩的真正的bug（不是「這也許是一個問題...」
  32     那樣的東西）。
  33   - 必須修正帶來如下後果的問題：編譯錯誤（對被標記爲CONFIG_BROKEN的例外），
  34     內核崩潰，掛起，數據損壞，真正的安全問題，或者一些類似「哦，這不
  35     好」的問題。簡短的說，就是一些致命的問題。
  36   - 沒有「理論上的競爭條件」，除非能給出競爭條件如何被利用的解釋。
  37   - 不能存在任何的「瑣碎的」修正（拼寫修正，去掉多餘空格之類的）。
  38   - 必須被相關子系統的維護者接受。
  39   - 必須遵循Documentation/translations/zh_TW/process/submitting-patches.rst里的規則。
  40
  41 向穩定版代碼樹提交補丁的過程：
  42 ------------------------------
  43
  44   - 在確認了補丁符合以上的規則後，將補丁發送到stable@vger.kernel.org。
  45   - 如果補丁被接受到隊列里，發送者會收到一個ACK回復，如果沒有被接受，收
  46     到的是NAK回復。回復需要幾天的時間，這取決於開發者的時間安排。
  47   - 被接受的補丁會被加到穩定版本隊列里，等待其他開發者的審查。
  48   - 安全方面的補丁不要發到這個列表，應該發送到security@kernel.org。
  49
  50 審查周期：
  51 ----------
  52
  53   - 當穩定版的維護者決定開始一個審查周期，補丁將被發送到審查委員會，以
  54     及被補丁影響的領域的維護者（除非提交者就是該領域的維護者）並且抄送
  55     到linux-kernel郵件列表。
  56   - 審查委員會有48小時的時間，用來決定給該補丁回復ACK還是NAK。
  57   - 如果委員會中有成員拒絕這個補丁，或者linux-kernel列表上有人反對這個
  58     補丁，並提出維護者和審查委員會之前沒有意識到的問題，補丁會從隊列中
  59     丟棄。
  60   - 在審查周期結束的時候，那些得到ACK回應的補丁將會被加入到最新的穩定版
  61     發布中，一個新的穩定版發布就此產生。
  62   - 安全性補丁將從內核安全小組那裡直接接收到穩定版代碼樹中，而不是通過
  63     通常的審查周期。請聯繫內核安全小組以獲得關於這個過程的更多細節。
  64
  65 審查委員會：
  66 ------------
  67   - 由一些自願承擔這項任務的內核開發者，和幾個非志願的組成。
  68