关于 Linux -stable 发行版你想知道的一切¶
关于什么样的补丁会被接受，什么样的补丁不会被接受进入 “-stable” 树的规则
它或等效的修复必须已经存在于 Linux 主线（上游）中。
It must be obviously correct and tested.
连同上下文在内，它不能超过 100 行。
它必须要么修复困扰人们的真实 bug，要么仅仅添加一个设备 ID。详细说明前者：
它修复诸如 oops、死机、数据损坏、真正的安全问题、硬件怪癖、构建错误（但不包括标记为 CONFIG_BROKEN 的内容），或者某些“噢，这可不太妙”的问题。
发行版内核用户报告的严重问题，如果修复了显著的性能或交互性问题，也可以被考虑。由于这些修复不是那么明显且具有更高的隐性回归风险，它们应该仅由发行版内核维护者提交，并包含一个指向 bugzilla 条目（如果存在）的附录以及关于用户可见影响的附加信息。
不要“这可能是一个问题……”类型的事情，比如“理论上的竞争条件”，除非同时提供了如何利用该 bug 的解释。
不要对用户没有好处的“微小”修复（拼写更改、空白字符清理等）。
向 -stable 树提交补丁的程序¶
注意
安全补丁不应（完全）由 -stable 审查流程处理，而应遵循 Documentation/process/security-bugs.rst 中的程序。
有三种向 -stable 树提交更改的选项
在你随后提交以纳入主线的补丁描述中添加一个“stable 标签”。
请 stable 团队挑选一个已经并入主线的补丁。
向 stable 团队提交一个等同于已并入主线更改的补丁。
以下各节更详细地描述了每个选项。
选项 1 是强烈推荐的，它是最简单也是最常见的。选项 2 主要用于在提交时未考虑向后移植的更改。选项 3 是前两个选项的替代方案，用于已并入主线的补丁需要进行调整才能应用于旧系列（例如由于 API 更改）的情况。
当使用选项 2 或 3 时，你可以请求将你的更改包含在特定的 stable 系列中。这样做时，请确保该修复或等效修复适用、已提交或已存在于所有仍在支持的较新 stable 树中。这是为了防止用户在更新时可能遇到的回归，例如如果为 5.19-rc1 合并的修复被向后移植到 5.10.y，但没有移植到 5.15.y。
选项 1¶
要让你提交以纳入主线的补丁随后自动被 stable 树挑选，请在签名区（sign-off area）添加此标签
Cc: stable@vger.kernel.org
在修复未公开的漏洞时，请改用 Cc: stable@kernel.org：这减少了通过 ‘git send-email’ 意外向公众暴露修复的机会，因为发送到该地址的邮件不会被投递到任何地方。
一旦补丁并入主线，它将被应用到 stable 树中，作者或子系统维护者无需做任何其他事情。
要向 stable 团队发送额外的说明，请使用 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 用于 stable 包含，则不必将 patch1 列为 patch2 的前提条件。
指出内核版本前提条件
Cc: <stable@vger.kernel.org> # 3.3.x
该标签的含义是
git cherry-pick <this commit>
从指定版本开始的每个 “-stable” 树。
请注意，如果 stable 团队可以从 Fixes: 标签推导出适当的版本，则这种标记是不必要的。
延迟挑选补丁
Cc: <stable@vger.kernel.org> # after -rc3
指出已知问题
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
此外，还有一种 stable 标签的变体，你可以用它来让 stable 团队的向后移植工具（例如 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 队列中，供其他开发人员和相关子系统维护者审查。
审查周期¶
当 -stable 维护者决定进行审查周期时，补丁将发送给审查委员会、补丁受影响区域的维护者（除非提交者是该区域的维护者），并抄送（CC:）至 linux-kernel 邮件列表。
审查委员会有 48 小时的时间来对补丁进行 ACK 或 NAK。
如果委员会成员拒绝该补丁，或者 linux-kernel 成员反对该补丁，提出了维护者和成员未意识到的问题，该补丁将被从队列中删除。
获得 ACK 的补丁将作为发布候选版本（-rc）的一部分再次发布，以供开发人员和测试人员测试。
通常只发布一个 -rc 版本，但是，如果有任何未解决的问题，某些补丁可能会被修改或删除，或者可能会排队加入额外的补丁。然后将发布并测试额外的 -rc 版本，直到没有发现问题为止。
可以通过在邮件列表上发送带有任何所需测试信息的“Tested-by:”电子邮件来对 -rc 版本做出响应。“Tested-by:”标签将被收集并添加到发布提交中。
在审查周期结束时，将发布包含所有排队和测试过的补丁的新 -stable 版本。
安全补丁将直接从内核安全团队接受进入 -stable 树，而不经过正常的审查周期。有关此程序的更多详细信息，请联系内核安全团队。
树（Trees）¶
无论是已完成版本还是进行中版本的补丁队列，都可以在以下位置找到
所有 stable 内核已定稿和打标签的发布版本可以在每个版本的独立分支中找到
所有 stable 内核版本的发布候选版本可以在以下位置找到
警告
-stable-rc 树是 stable-queue 树的时间快照，会频繁更改，因此会经常进行变基。它应该仅用于测试目的（例如供 CI 系统使用）。
审查委员会¶
这由许多自愿承担此任务的内核开发人员组成，其中也有少数并非自愿的。