关于 Linux -stable 版本你需要知道的一切¶
关于哪些类型的补丁会被接受，哪些类型的补丁不会被接受到 “-stable” 分支的规则
它或等效的修复必须已经存在于 Linux 主线（上游）。
它必须是显而易见的正确且经过测试的。
它不能大于 100 行，包括上下文。
它必须修复真正困扰人们的 bug 或只是添加一个设备 ID。 为了详细说明前者
它修复诸如 oops、挂起、数据损坏、真正的安全问题、硬件怪癖、构建错误（但不适用于标记为 CONFIG_BROKEN 的内容）或某些“哦，那不好”的问题。
如果修复了显著的性能或交互性问题，也可以考虑发行版内核用户报告的严重问题。 由于这些修复并不那么明显，并且存在细微回归的较高风险，因此它们应仅由发行版内核维护者提交，并包括一个指向错误报告条目的附录（如果存在）以及有关用户可见影响的附加信息。
没有“这可能是一个问题...”之类的事情，比如“理论上的竞争条件”，除非还提供了如何利用该 bug 的解释。
没有对用户没有好处的“琐碎”修复（拼写更改、空白清理等）。
向 -stable 分支提交补丁的步骤¶
注意
安全补丁不应（仅）由 -stable 审查流程处理，而应遵循 Documentation/process/security-bugs.rst 中的程序。
有三种选项可以向 -stable 分支提交更改
在您提交以包含到主线的补丁的描述中添加一个“稳定标签”。
要求稳定团队拾取已经主线的补丁。
向稳定团队提交一个等效于已经主线的更改的补丁。
以下各节将更详细地描述每个选项。
选项 1 是强烈首选的，它是最简单和最常见的。选项 2 主要用于在提交时没有考虑反向移植的更改。选项 3 是前两个选项的替代方案，用于主线补丁需要调整以应用于较旧系列（例如，由于 API 更改）的情况。
当使用选项 2 或 3 时，您可以要求将您的更改包含在特定的稳定系列中。 执行此操作时，请确保该修复或等效项适用于、已提交或已经存在于所有仍受支持的较新稳定分支中。 这是为了防止用户在更新时可能稍后遇到的回归，例如，如果为 5.19-rc1 合并的修复程序会反向移植到 5.10.y，但不会反向移植到 5.15.y。
选项 1¶
为了使您提交以包含到主线的补丁稍后自动被稳定分支拾取，请在签名区域中添加此标签
修复未发布漏洞时，请使用 Cc: [email protected] 代替：它可以降低通过 'git send-email' 意外向公众暴露修复程序的风险，因为发送到该地址的邮件不会传递到任何地方。
一旦补丁被主线化，它将被应用到稳定分支，而无需作者或子系统维护者执行任何其他操作。
要向稳定团队发送其他说明，请使用 shell 样式的内联注释来传递任意或预定义的注释
指定 cherry picking 的任何其他补丁先决条件
Cc: <[email protected]> # 3.3.x: a1f84a3: sched: Check for idle Cc: <[email protected]> # 3.3.x: 1b9508f: sched: Rate-limit newidle Cc: <[email protected]> # 3.3.x: fd21073: sched: Fix affinity logic Cc: <[email protected]> # 3.3.x Signed-off-by: Ingo Molnar <[email protected]>
标签序列的含义是
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: <[email protected]> # 3.3.x
该标签的含义是
git cherry-pick <this commit>
对于以指定版本开始的每个 “-stable” 分支。
请注意，如果稳定团队可以从 Fixes: 标签推导出适当的版本，则无需此类标记。
延迟拾取补丁
Cc: <[email protected]> # after -rc3
指出已知问题
Cc: <[email protected]> # see patch description, needs adjustments for <= 6.3
此外，您还可以使用稳定标签的变体来使稳定团队的反向移植工具（例如 AUTOSEL 或查找包含 'Fixes:' 标签的提交的脚本）忽略更改
Cc: <[email protected]> # 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 成员反对该补丁，提出维护者和成员没有意识到的问题，则该补丁将从队列中删除。
ACKed 补丁将作为发布候选版本 (-rc) 再次发布，以供开发人员和测试人员测试。
通常只进行一个 -rc 版本发布，但是如果存在任何未解决的问题，则可能会修改或删除某些补丁，或者可能会将其他补丁排队。 然后发布并测试其他 -rc 版本，直到未发现任何问题。
可以通过发送带有任何所需测试信息的“Tested-by:” 电子邮件在邮件列表上完成对 -rc 版本的响应。“Tested-by:” 标签将被收集并添加到发布提交中。
在审查周期结束时，将发布新的 -stable 版本，其中包含所有排队和测试的补丁。
安全补丁将直接从内核安全团队接受到 -stable 分支中，而无需经过正常的审查周期。 请联系内核安全团队以获取有关此程序的更多详细信息。
分支¶
已完成版本和正在进行版本的补丁队列都可以在以下位置找到
所有稳定内核的最终和标记的发行版本都可以在每个版本的单独分支中找到
所有稳定内核版本的发布候选版本都可以在以下位置找到
警告
-stable-rc 分支是 stable-queue 分支的时间快照，会频繁更改，因此会经常进行变基。 它仅应用于测试目的（例如，由 CI 系统使用）。
审查委员会¶
它由许多自愿执行此任务的内核开发人员以及一些没有自愿执行此任务的内核开发人员组成。