Bug fix为什么不能先进Release分支再进主分支？

今天和同事争论为什么Bug fix不能先进release分支再进主分支，我只能干巴巴的回答这样做不优雅，不能先CD再CI。问了问大模型，发现AI确实比较擅长做以理服人的事，哪怕它是幻觉，都让你觉得好有道理的样子。

看看AI是怎么回答的：

这是个非常棒的问题！这触及了 Linux 内核开发流程的核心设计哲学：稳定分支的纯洁性和主线的权威性。

简单来说，稳定分支只接受经过主线验证的、最小化的、必需的修复。让修复先进稳定分支再进主线，违背了这个核心原则，并会带来一系列严重问题：

破坏“稳定分支”的“稳定”定义：
- 代码冻结： 当一个版本被标记为稳定分支（如 6.1.y）时，就意味着它的代码基础（除了必要的修复）是冻结的。不允许添加新功能或进行大的重构。
- 最小化变更： 进入稳定分支的唯一东西应该是针对已知问题的、经过主线充分验证的、尽可能小的修复。目标是最大程度地减少引入新问题的风险。
- 如果修复先进入稳定分支： 这个修复本身就是一个新的、未经主线充分验证的变更。它可能会引入新的、更严重的 Bug，或者与主线正在进行的其他开发产生冲突，从而直接破坏了稳定分支的稳定性。
绕过主线的严格审查：
- 主线是核心战场： 所有重大的开发、重构、新功能以及与之相关的 Bug 修复，都必须首先发生在主线分支。这里有最广泛的开发者群体、最严格的代码审查流程、最完善的自动化测试基础设施（虽然内核测试很复杂）。
- 稳定分支审查相对宽松： 稳定分支维护者（如 Greg KH）和子系统的稳定分支维护者主要关注的是：
  - 这个修复是否真的需要 Backport？
  - 这个修复是否安全（不会破坏现有功能）？
  - 这个修复是否正确地适配到了旧代码上？
  - 他们不负责对修复本身的正确性进行深度的、如同主线级别的原始审查。他们信任这个修复已经在主线被“烤”过。
- 如果修复先进入稳定分支： 相当于让一个未经主线充分“烤制”和审查的代码片段，绕过了最严格的审核流程，直接进入了面向亿万用户的生产环境（稳定分支最终会发布给用户）。这大大增加了将错误修复引入稳定版本的风险。
Backport 冲突和复杂性剧增：
- 主线是单一源头： 目前的标准流程是，修复只在一个地方（主线）被设计和验证。然后，如果需要，由专家将其适配（Backport）到多个稳定分支。适配过程可能会遇到冲突，但冲突的来源是清晰的：稳定分支代码落后于主线。
- 如果修复先进入稳定分支： 想象一下，一个修复先在稳定分支 A（如 6.1.y）上开发并提交。现在需要把这个修复：
  - 合并到主线： 主线代码可能已经发生了巨大变化（新功能、重构），导致这个为旧代码设计的修复在主线根本无法直接应用，或者需要重大重写才能适应主线的新结构。这比 Backport 要困难得多！
  - Backport 到其他稳定分支： 比如 Backport 到更老的 LTS 分支 B（如 5.15.y）。维护者 B 现在需要参考的源头不是权威的、最新的主线修复，而是另一个稳定分支 A 上的一个定制版本。这增加了理解的复杂性和出错的可能性。稳定分支之间不应该互相作为源头。
维护噩梦和责任模糊：
- 清晰的源头： 当前模式下，任何稳定分支上的修复，都能清晰追溯到主线上的原始提交。这简化了问题追踪、责任归属和代码理解。
- 如果修复先进入稳定分支： 同一个 Bug 的修复，在主线、稳定分支 A、稳定分支 B 上可能是不同的代码（因为需要适应各自不同的代码环境）。这会导致：
  - 代码碎片化： 同一个问题的修复存在多个变体。
  - 理解困难： 开发者需要理解多个版本，而不是一个权威版本。
  - 维护负担： 如果后来在主线发现了这个修复本身的问题，需要再分别修复所有稳定分支上的变体。工作量剧增。
  - 责任模糊： 原始修复的“正确”版本在哪里？是稳定分支 A 上的那个吗？这打破了主线作为单一权威源头的模式。
违背开发流程：
- 内核开发者的主要工作环境和提交目标就是主线。要求他们先在某个特定的、可能已经过时的稳定分支上开发修复，然后再想办法弄回主线，是极其低效且不符合开发者习惯的。这会严重拖慢开发速度。