您想了解的关于 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 系统使用）。
审查委员会¶
这由一些自愿承担此任务的内核开发人员和少数非自愿者组成。