LWN：滚动发布的稳定版内核！
关注了就能看到更多这么棒的文章哦～
Rolling stable kernels
By Jake Edge
October 6, 2021
OSSNA
DeepL assisted translation
https://lwn.net/Articles/871989/
Sasha Levin 是 stable kernel 维护者之一，2021 年北美开源峰会上他发表了一个对 stable
tree 采用新的方式来处理的建议。他指出，在内核的绝大多数历史中，版本号都没那么重要，但版本号的命名规则给人们的印象是它们是有意义的，这就导致了人们对内核的看法与其实际维护方式之间产生了脱节。他建议制作一个 "rolling stable" release，来给用户提供他们真正所需要的东西，也就是及时地 fix 他们的内核中的问题，而不用强迫他们选择切换到新的一个版本号代表的版本。
Context
他首先介绍了内核版本命名规范（kernel versioning scheme）的历史，以及这些年来它们是如何演变的。从 0.01 版本开始，Linus Torvalds 就使用了一个在小型项目中经常采用的很常见的版本号机制：如果只有一些小的新增功能，就只把版本号提高一点点；而如果有更大的功能或更多的功能加入进来，就多提高一些。当 Torvalds 认为他开发出来的东西已经足够让人们广泛使用时，他就发布了 Linux 1.0。
[Sasha Levin]
在 1.0 版本发布之后，Linux 有了更多的用户。这些用户不一定都是内核开发者。他们可能是想开发一些应用程序，来运行他们自己的工作任务（workload）。他们不想使用开发中的版本的内核，于是提出了 stable kernel 这个想法。内核于是就采取了这样的模式，用一个 branch 来维护 stable kernel，另一个分支则用来进行活跃的开发。
Bug Fix 会从 development branch 来 backport 到 stable branch 上。等 development branch 准备好可以进行发布了，那么它就会成为下一个 stable branch。内核继续沿用了之前的做法，也就是在增加了新的功能（feature）的时候来增大版本号，但由于缺乏集中管理，因此总是不确定什么时候可以发布新版本。Levin 指出，在 2.0 版本到 2.6 版本内核之间的那段时间，这个过程看起来总是停滞不前的状态。
从 2.4 到 2.6 的过程则是 "一次花了三年时间的不断探索"。他说，这下社区就认识到这个流程是行不通的，最终会导致 "总是需要不确定的甚至无限长的时间才能进入下一版本"。因此，在内核 2.6 时代，内核开发者想出了一个新的方法，他们不再基于 feature 来发布新版本，而是改为基于时间点进行发布的流程。
最终，演化出来的做法变为了：每 10 周左右的时间发布一次新的 kernel。而内核开发者也开始宣传说版本号并不代表什么了，而且确实它们也没那么重要了。但这是一个典型的 "engineering doing marketing （工程师做营销）" 的例子，Levin 认为，因为版本号的命名规范并没有随着改动，同时也没有将版本号不再代表什么的这个观点明确地传达给客户。
这就导致了现在熟悉的工作流程，也就是两周的合并窗口、接下来是七八个 release candidates，然后得出一个正式版本。每个内核都被人们认为是稳定的，所以不再有单独的 development kernel 分支了。他说，有一些客户想要达到更高的稳定性，这就是长期稳定版本（LTS）的想法来源了。这种工作模式运行得很好，于是内核在 2.6.x 系列上保持了大约 8 年时间。
Expectations
但在转向新的这种 time-based 开发流程中也犯了一些错误。虽然内核开发人员不再注重版本号，但客户这边并没有忽视它，而且社区也没有很好地推广宣传这个 time-based version 的想法。由于版本号数字仍然存在，客户总是认为它们是有含义的，所以在他们看来，从 3.20 到 4.0 的版本号转变是 "big and scary，非常大的可怕改动"，因为他们看到主版本号已经改变了。
在 2.6.x 上停留了这么久也带来了一些影响。当时这么做的原因中一部分是为了帮助客户适应新系统，但在某种程度上来说让他们过得太舒服了。当内核开发者想要迁移到 3.0 时，他们发现一些产品中已经嵌入了一些关于内核版本号的各种各样的假设，所以当时开发者们不得不增加一些变通方法来绕过。
Levin 说，客户已经习惯了小版本的更新（例如从 2.6.y 到 2.6.y+1），但是他们也开始对版本号的含义做出了很多猜想性地判定。比如一旦 minor number 已经非常大了，他们就会把这个版本它当作一个 "more minor，更加不重要" 的版本变化。在他们眼里，2.6.1 到 2.6.2 是一个重要的改动，需要立即升级，但 2.6.30 到 2.6.31 的改动则不那么重要，可以推迟到 2.6.35 或其他时候来升级。而事实上对于内核社区来说，这两种情况根本没有什么区别。
为了要解决这个问题，大家计划转向 3.0，并在每次发布时都对第二个数字（次要版本）进行增长，也就事实上放弃了在 mainline 发布时使用版本号中的第三个数字。Levin 称这是 "finger and toes" 方式的版本号命名方式，因为 Torvalds 说他一般也就愿意数到大约 20 个 "minor" 版本，然后就不愿意继续数数了，而需要开始增加主版本号（major version number）。所以在 3.19 之后，人们发布了 4.0。
他说，对于内核开发人员来说，版本号除了用来衡量在时间线上所处的位置之外，仍然是没有任何其他意义的。用户应该要运行最新的版本。但是，如果你告诉客户他们需要从 3.20 升级到 4.0，他们会认为这是一项需要仔细规划以及书面申请的持续多年的一个工作，"所以他们只会在有时间的时候才去做这件事，事实上也就永远不会做了"。从 3.20 到 4.0 在他们看来是一个很大的变动，而 4.0 到 4.2 的变动则似乎要小得多，尽管后者加入的改动数量大约是前者的两倍。
随着时间的推移，内核社区在 testing、避免性能 regression、以及不破坏用户空间等等方面已经做得更好了，用户应该更容易迁移了。但是，用户这边仍然有不少阻力做这件事，部分原因就是内核开发者还没有向用户讲清楚并推广内核命名的这个规划。
然而，一些发行版和一部分用户已经开始听从了内核开发者的意见，并且正在不断跟上最新版的内核或 LTS 版本。他们已经认识到这些版本只是基于时间来命名的，所以升级事实上并不可怕。除此之外，用户是希望得到最新的那些亮眼功能（"BPF，新的 I/O scheduler，他们想要尽量提升性能"），而且他们想马上就能得到所有这些优势，不希望把更多的新功能 backport 到旧版本内核上。他们还希望能有频繁的安全更新。所有这些都与内核开发者的愿望相吻合，并且能够实现。
Enterprise kernel 现在不那么流行了，这里的一部分原因是 "维护某个古老的内核的困难度已经加倍增长"。内核的发展如此之快，以至于有越来越多的 Backport 动作需要做，每一个都会使得维护 Enterprise kernel 变得更加复杂。实际上，大多数企业内核已经变成了 "frankenkernels"，它们带有了当前最新版本内核大部分功能的 backport 代码，因此它们声称的版本号根本就不准确。
Rolling
在 "LTS world" （也就是采用了 LTS 的做法之后） 中，用户会选择一个内核的 LTS 系列，比如 5.10.x，并不断将他们的内核升级到该系列的最新版本，直到不可能再升级为止。当这种情况发生时，他们就会选择一个新的 LTS 系列，切换到该系列，从那里继续重复之前的做法。内核开发者一直希望让他们更早地转换到新版本，也就是当下一个版本出来时（在这种情况下，5.11.x），他们就应该开始使用这个新的系列了。
但是，要进行这种转换的话就需要用户专门的努力。他们也必须选择一个时间来做，但是 "从来没有一个好的时间点会是 '我们该要改变我们的内核了'，尤其是这么频繁的情况"。除此之外，在中途切换到一个新的内核 Git branh 还会碰到一些技术上的障碍，比如可能会有一些 patch 需要被 forward-ported。
因此，Levin 问道："可以做些什么来改善这个过程？" 不管是主版本号、次版本号还是稳定版本之间的改动，内核社区都提供了同样的保证："确保它不会破坏用户空间"。它可能会意外地导致用户空间出现一些问题，但如果这种情况出现了，那么就会在 kernel 里面进行 fix。不过，这些破坏可能发生在任何类型的升级上，没有哪种类型的升级更容易、或更不容易发生意外破坏。"版本号仍然是，真的真的不重要"。
我们的想法是 "消除摩擦点，eliminate the friction point"，即客户需要选择切换到下一个系列。目前，稳定版和 LTS tree 的每个 mainline 版本都有一个 branch，而事实上，每次 Torvalds 发布版本时，stable tree 都会进行一次 fork。mainline Git tree 直接继续往下走，直到下一个合并窗口开启的时候，那些为下一个版本而准备的 patch 就会被提交到 main branch 上。而对于 stable tree 来说则没有一个相应的机制。
stable 版本的维护者们希望开始进行一个不一样的做法，也就是使用户在每次转移到一个新系列时不需要切换 branch。它保证是与当前的代码 tree 质量相同，并按相同的时间表来推进。但是它默认是向前滚动的，就像 Torvalds 的 tree 一样。
我们的想法是使用 "Git 的魔法" 来实现这一切。不再进行 cherry pick 来挑选 patch。取而代之的是使用 "Git merge 的改动版本"，这种方式保留了现有 stable tree 中的 SHA1 值。Git tag 也得以保留，而保留 SHA1 就意味着那些希望避免受到供应链攻击（supply-chain attacks）而想要进行验证的人可以更容易地利用 SHA1 值进行验证。bisection 二分 Git 操作仍然是有效，patch author 不会变动，所以 Git blame 也仍然有效，等等等等。他说，stable tree 的维护者只是 "稍微进行了一些 Git 操作，让人觉得所有这些开发都发生在一个分支里"。这个改动所变化的仅仅是 "我们向终端用户展示 kernel tree 的方式"。
目前，用户会工作在某一个 stable branch 或某一个一个 LTS branch 上，但在这种模式下，他们其实工作环境变成了 the stable or LTS branch。他们不是在随机使用一些内核版本，而是在使用内核开发者推荐的拥有最佳体验的版本。由此，他们将获得所有最新的功能、bug fix 以及 security update。
Concerns
当然，他也从公司和用户的反馈中听到了一些对这种方法的担忧。首先，在滚动模式下，对测试的需求增加了，这个工作被推给了用户。但他并不同意这种看法。目前用户认为如果他们从 x.y.50 到 x.y.51，他们不需要重新进行很多测试，但事实并非如此。滚动发布的情况下也是如此。只要内核发生了改动，就必须进行测试。
另一个令人担心的地方是，滚动发布模型有效地 "隐藏了它内部的合并窗口"。某一天，这个 rolling stable tree 可能是在 5.7.15，而下一天可能就是在 5.8.1 了。在这个 pull 合并中，有很多 patch 是来自 5.8 的合并窗口，这是一个很大的变动。但他认为这一切又都回到了测试这一点上。有可能合并窗口引入了很多错误，但也有可能一个 stable patch 也可能会引入很多错误。
他说，原来的时间表仍旧保持不变。这些 rolling stable 和 LTS branch 只是当前 stable tree 的衍生版本。新的模式并不要求用户要按照一个新的计划时间表来做事，新模式中仅仅是在用户决定升级和做 Git pull 时提供给他们最新的内核而已。
滚动模式不是一个激进的变革，也不是一个新想法。他说："如果你使用 Debian 的话，这一直是它的工作方式"。Debian testing kernel 或多或少相当于 rolling stable branch。他相信滚动发布模式会成功，因为有一些发行版和设备已经在某种形式上使用该模式了，"他们喜欢这种工作方式"。Levin 说，总的来说，这是一个尝试，以解决过去在版本划分方面所犯的一些错误，以及让用户清楚稳定版开发者希望用户应该如何使用。
这个 rolling stable 和 rolling LTS branches 已经存在了。截至本文撰写时，rolling stable 是 5.14.9，而 rolling LTS 则是 5.10.70。如前所述，它们只是现有 stable 和 LTS branch 的衍生版本，其中没有任何内容是其他两个分支中所没有的。"如果你想遵循 Linux 内核的开发理念，这些分支将使你变得超级容易"。
在回答某个问题时，Levin 说，从某个 patch 在 mainline 上发布，到这个改动在 rolling stable tree 上出现，还是需要一段时间。等 5.15 版本发布之后，他们会一直等到 5.16 合并窗口关闭后再把 5.15 的改动纳入进来。
还有人问他 LTS 版本的未来是怎样。他指出，LTS 的想法有些矛盾。一方面，稳定版的维护者建议永远使用最新的 LTS，但另一方面，LTS 版本的支持期为五年。他个人希望 LTS 版本随着时间的推移而消失，但他认为这不会很快发生，因为没有足够的测试和鉴定工作。不过，他预计在 20 年内，将不会有 LTS 内核。
[感谢 LWN 订户支持编者去西雅图参加北美开源峰会 Open Source Summit North America。]
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～