您想了解的關於 Linux -stable 版本的一切¶
關於哪些補丁被接受、哪些不被接受到“-stable”樹中的規則
它或等效的修復必須已經存在於 Linux 主線 (upstream) 中。
它必須顯而易見地正確且經過測試。
它不能超過 100 行（含上下文）。
它必須遵循 Documentation/process/submitting-patches.rst 的規則。
它必須修復一個困擾人們的真實 Bug，或者僅僅新增一個裝置 ID。關於前者的詳細說明：
它修復了一個問題，例如 oops、掛起、資料損壞、真實的安全問題、硬體怪癖、構建錯誤（但不是針對標記為 CONFIG_BROKEN 的內容），或一些“哦，那不好”的問題。
如果發行版核心的使用者報告的嚴重問題修復了顯著的效能或互動性問題，也可能被考慮。由於這些修復不那麼明顯，且存在微妙迴歸的較高風險，因此它們應僅由發行版核心維護者提交，並應包含一個附錄，如果存在則連結到 bugzilla 條目，以及關於使用者可見影響的額外資訊。
沒有“這可能是一個問題……”型別的修復，例如“理論上的競態條件”，除非同時提供瞭如何利用該 Bug 的解釋。
沒有對使用者無益的“瑣碎”修復（拼寫更改、空白清理等）。
向 -stable 樹提交補丁的程式¶
注意
安全補丁不應（單獨）透過 -stable 審查流程處理，而應遵循 Documentation/process/security-bugs.rst 中的程式。
向 -stable 樹提交更改有三種選擇
在您提交用於主線包含的補丁描述中新增一個“stable 標籤”。
請求 stable 團隊接收一個已進入主線的補丁。
向 stable 團隊提交一個與已進入主線的更改等效的補丁。
以下部分將更詳細地描述每個選項。
選項 1 是強烈推薦的，它是最簡單和最常見的。選項 2 主要用於在提交時未考慮向後移植的更改。選項 3 是前兩個選項的替代方案，適用於主線補丁需要調整以適用於舊系列版本的情況（例如由於 API 更改）。
當使用選項 2 或 3 時，您可以請求將您的更改包含在特定的穩定系列中。這樣做時，請確保該修復或等效的修復適用於所有仍然受支援的較新穩定樹，且已提交或已存在於其中。這是為了防止使用者在更新時可能遇到的迴歸，例如，如果一個合併到 5.19-rc1 的修復被反向移植到 5.10.y，但沒有反向移植到 5.15.y。
選項 1¶
要使您提交的主線包含補丁隨後自動被穩定樹接收，請在簽名區域新增此標籤：
Cc: stable@vger.kernel.org
當修復未公開的漏洞時，請改用 Cc: stable@kernel.org：這降低了透過“git send-email”意外將修復暴露給公眾的機會，因為傳送到該地址的郵件不會被投遞到任何地方。
一旦補丁進入主線，它將被應用到穩定樹，無需作者或子系統維護者做任何其他事情。
要向穩定團隊傳送額外指令，請使用 shell 風格的內聯註釋來傳遞任意或預定義的備註
指定任何額外的補丁先決條件以便進行挑選（cherry picking）
Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic Cc: <stable@vger.kernel.org> # 3.3.x Signed-off-by: Ingo Molnar <mingo@elte.hu>
標籤序列的含義是
git cherry-pick a1f84a3 git cherry-pick 1b9508f git cherry-pick fd21073 git cherry-pick <this commit>
請注意，對於補丁系列，您無需將系列中存在的補丁列為先決條件。例如，如果您有以下補丁系列：
patch1 patch2
其中 patch2 依賴於 patch1，如果您已將 patch1 標記為穩定版本包含，則無需將 patch1 列為 patch2 的先決條件。
指出核心版本先決條件
Cc: <stable@vger.kernel.org> # 3.3.x
該標籤的含義是
git cherry-pick <this commit>
對於從指定版本開始的每個“-stable”樹。
請注意，如果穩定團隊可以從 Fixes: 標籤推匯出適當的版本，則無需進行此類標記。
延遲接收補丁
Cc: <stable@vger.kernel.org> # after -rc3
指出已知問題
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
此外，還有一種穩定標籤的變體，您可以使用它來使穩定團隊的反向移植工具（例如 AUTOSEL 或查詢包含“Fixes:”標籤提交的指令碼）忽略某個更改：
Cc: <stable+noautosel@kernel.org> # reason goes here, and must be present
選項 2¶
如果補丁已合併到主線，請傳送電子郵件至 stable@vger.kernel.org，郵件中包含補丁的主題、提交 ID、您認為應應用它的原因，以及您希望將其應用於哪些核心版本。
選項 3¶
在驗證補丁遵循上述規則後，將其傳送至 stable@vger.kernel.org，並提及您希望將其應用於的核心版本。這樣做時，您必須在提交的更改日誌中以提交文字上方單獨的一行註明上游提交 ID，如下所示：
commit <sha1> upstream.
或者
[ Upstream commit <sha1> ]
如果提交的補丁與原始上游補丁有所不同（例如因為它必須根據舊的 API 進行調整），則必須在補丁描述中非常清楚地記錄和說明理由。
提交之後¶
當補丁被接受進入佇列時，傳送者將收到 ACK；如果補丁被拒絕，則收到 NAK。此響應可能需要幾天時間，具體取決於穩定團隊成員的日程安排。
如果被接受，補丁將被新增到 -stable 佇列中，以供其他開發人員和相關子系統維護者審查。
審查週期¶
當 -stable 維護者決定進行審查週期時，補丁將被髮送到審查委員會，以及受補丁影響區域的維護者（除非提交者是該區域的維護者），並抄送至 linux-kernel 郵件列表。
審查委員會有 48 小時來 ACK 或 NAK 補丁。
如果補丁被委員會成員拒絕，或者 linux-kernel 成員反對補丁，提出維護者和成員未意識到的問題，該補丁將從佇列中刪除。
被 ACK 的補丁將再次作為釋出候選版本 (-rc) 的一部分發布，供開發人員和測試人員測試。
通常只發佈一個 -rc 版本，但是如果存在任何未解決的問題，一些補丁可能會被修改或刪除，或者可能會排隊額外的補丁。然後會發布並測試額外的 -rc 版本，直到沒有發現問題為止。
可以透過向郵件列表傳送帶有任何所需測試資訊的“Tested-by:”電子郵件來回應 -rc 版本。“Tested-by:”標籤將被收集並新增到釋出提交中。
在審查週期結束時，新的 -stable 版本將釋出，其中包含所有已排隊和已測試的補丁。
安全補丁將直接從安全核心團隊接受進入 -stable 樹，而不經過正常的審查週期。有關此程式的更多詳細資訊，請聯絡核心安全團隊。
程式碼庫¶
已完成版本和正在進行中的版本的補丁佇列可在以下位置找到：
所有穩定核心的最終標記版本可在每個版本的單獨分支中找到：
所有穩定核心版本的釋出候選版可在以下位置找到：
警告
“-stable-rc”樹是“stable-queue”樹的時間快照，會頻繁更改，因此會經常 rebase。它僅應用於測試目的（例如，供 CI 系統使用）。
審查委員會¶
這由一些自願承擔此任務的核心開發人員和少數非自願者組成。