A last look at the 4.4 stable series
Linus Torvalds 在 2016 年 1 月 10 日的时候 发布了4.4 kernel 然后就马上投入到 4.5 的全新领域里去了。从他看来这个版本已经完结了，但是对世界上绝大多数人来说，4.4 版本刚刚开始，而且在后续演化成为了第一个支持超过两年的长期稳定版本（long-term-release）。事实上 4.4 版本成为了 kernel 项目历史上支持时间最长、使用最广泛的版本之一（统计到目前为止）。它也被部署在了大量的 Android 设备和其他地方。最后一版 4.4 stable 版本是在 2 月 3 日发布的，这已经是 4.4 完结之后的六年多的时候了。现在是时候看看 4.4 在稳定期内有了哪些变动。
在 4.4 的支持期的 2216 天里发布了 302 个 stable 版本更新。相当于在这 6 年里大约每周有一个版本。这些版本为 "stable" kernel 添加了 18974 个 non-merge changeset（平均每天大约有 8.6 个 patch）。经过这些工作，在 4.4 内核里增加了近 90,000 行代码。在此期间也新增了 72 个源代码文件。
Contributing developers
因此，4.4 stable 这一系列发布在某些方面看起来就像另一个在并行进行的开发周期，而且包含了更多的 patch。其他也有不少数字很大，在这六年中，添加到 4.4 中的 fix 是由 3528 名开发者所贡献的，代表了将近 500 个不同的公司/组织。内核开发者可能都挺喜欢增加新的功能，但最终，几乎所有的人最终也都投入到 bug fix 里面来了。最主要的 bug fix 参与者是：
Table 1: Top bug fixes in 4.4.x
Developer | Changesets | Pct |
Greg Kroah-Hartman | 419 | 2.2% |
Eric Dumazet | 367 | 1.9% |
Takashi Iwai | 345 | 1.8% |
Arnd Bergmann | 336 | 1.8% |
Johan Hovold | 327 | 1.7% |
Dan Carpenter | 288 | 1.5% |
Thomas Gleixner | 168 | 0.9% |
Al Viro | 121 | 0.6% |
Eric Biggers | 118 | 0.6% |
Colin Ian King | 108 | 0.6% |
Linus Torvalds | 92 | 0.5% |
Geert Uytterhoeven | 87 | 0.5% |
Xin Long | 86 | 0.5% |
Jan Kara | 84 | 0.4% |
Nathan Chancellor | 84 | 0.4% |
Alan Stern | 82 | 0.4% |
Steven Rostedt (VMware) | 82 | 0.4% |
Hans de Goede | 81 | 0.4% |
Cong Wang | 80 | 0.4% |
Christophe JAILLET | 79 | 0.4% |
请注意，Greg Kroah-Hartman 的大部分 "fix"实际上都是那些用来标记每个版本的 302 个 git tag，此外还有 117 个实际 fix。根据哪些开发者参与进来了，就可以看出 bug 主要出现在哪些领域。例如，Eric Dumazet 是 networking 的，Takashi Iwai 是 sound 维护者。除此之外，Arnd Bergmann 在修复整个内核代码树中的问题上都投入了大量的精力，Dan Carpenter 也是如此。Johan Hovald 工作遍及整个 driver 代码 tree，重点是 USB 子系统。值得注意的是，哪怕是那些 fix 最多的贡献者，他们各自负责的 fix 也不到总数的 2%。
从 tester 以及 reviewer 方面能看到另一些不同的信息：
Test and review credits in 4.4.x | |
Tested-by | ||
Guenter Roeck | 75 | 3.7% |
Pavel Machek | 57 | 2.8% |
Jon Hunter | 55 | 2.7% |
Linux Kernel Functional Testing | 53 | 2.6% |
Shuah Khan | 50 | 2.4% |
Andrey Konovalov | 44 | 2.1% |
Aaron Brown | 44 | 2.1% |
Andrew Bowers | 38 | 1.9% |
Dmitry Vyukov | 35 | 1.7% |
Arnaldo Carvalho de Melo | 27 | 1.3% |
Borislav Petkov | 21 | 1.0% |
Jason Self | 17 | 0.8% |
Stan Johnson | 16 | 0.8% |
Joe Lawrence | 15 | 0.7% |
Marc Zyngier | 12 | 0.6% |
Jon Masters | 12 | 0.6% |
Krishneil Singh | 12 | 0.6% |
4.4 中只有 1527 个 patch 包含了 Tested-by tag，这只占总数的 8%。这似乎有点令人惊讶，因为这些 patch 中每一个都是为了 fix，所以应该能简单 test 验证这个 fix 是否奏效。
Reviewed-by 一栏的前几行并不特别令人惊讶，Kroah-Hartman 和 Christoph Hellwig 一般都会做很多 review，David Sterba 是 Btrfs 的维护者。接下来的几个名字，Alexey Makhalov，Matt Helsley 和 Bo Gan，就有点令人惊讶了：Makhalov 和 Helsley 在内核中只有一个自己撰写的 patch，而 Gan 一个都没有。通过挖掘具体的 git log，可以看到他们三位在 2018 年中期的时候有大量的贡献。实际上，这三位开发人员在向 4.4 内核进行 backport 移植 Meltdown 和 Spectre fix 程序方面发挥了很大作用。
Patch review and selection
有 4101 个合入 4.4 的 patch 都至少包含了一个 Reviewed-by 标签，这占了总数的 22%。相比之下，5.16 版中有 37% 的 patch 含有这种 tag。人们可能会得出结论，进入 stable 内核的 patch 得到的 review 比起合理数量来说偏少，但也可能是因为 Reviewed-by tag 是最近开始逐渐广泛用起来的。进入 4.5 的 patch 里，只有 19% 的 patch 有 Reviewed-by tag，这一事实也基本证明了这一点。
稳定版更新中 fix 的错误是如何被发现的？可以从用于表彰报告错误的人的 Reported-by 标签中找到一些线索。4.4.x 中的 3529 个 commit 都包含了这样的 tag，其中最活跃的报告者如下：
Table 3: Top bug reporters in 4.4.x
Reporter | Reports | Pct |
Syzbot | 684 | 17.1% |
Dmitry Vyukov | 146 | 3.7% |
Hulk Robot | 145 | 3.6% |
kernel test robot | 88 | 2.2% |
Andrey Konovalov | 85 | 2.1% |
Dan Carpenter | 69 | 1.7% |
Ben Hutchings | 39 | 1.0% |
Jann Horn | 31 | 0.8% |
kbuild test robot | 30 | 0.8% |
Guenter Roeck | 23 | 0.6% |
Al Viro | 20 | 0.5% |
Wen Xu | 18 | 0.5% |
Linus Torvalds | 16 | 0.4% |
Jianlin Shi | 16 | 0.4% |
Geert Uytterhoeven | 14 | 0.4% |
Julien Grall | 14 | 0.4% |
Eric Dumazet | 13 | 0.3% |
Tetsuo Handa | 13 | 0.3% |
Eric Biggers | 13 | 0.3% |
Alexander Potapenko | 13 | 0.3% |
Dmitry Vyukov 是 Syzbot 的开发者，所以前两行其实可以合并，这说明一个开发者就报告出了 tag 中标记出来的将近 21% 的需要在 4.4.x 中 fix 的问题，这个数字令人印象深刻。其他自动化测试系统又给出了 6.6% 的 bug。其他一些排在前列的 bug 报告者几乎也可以确定是在用他们自己的工具来寻找错误。这些 bug 全部都是在用户遇到之前就被 fix 了的问题，这应该说是一件好事。
同样是关于 tag 的话题：维护者在 patch 的 CC 列表中添加 stable@vger.kernel.org，用来标记这个 patch 也应该放到 stable kernel 里面去。在 4.4.x 的过程中，有 3446 个补丁（占总数的 18%多一点）是用这种方式标记起来的。因此很明显，CC 列表这种方式并不是大多数 patch 进入 stable update 的主要路径。在某些子系统中（ 尤其是 networking ），维护者会维护一个单独的 stable 相关 patch 队列，并在积极地阻止开发者们自己来决定哪些 patch 需要放到 stable。
但大多数时候，patch 是由 stable kernel 内核维护者自己来挑选的，要么是手工挑选，要么是使用了机器学习系统。这个过程经常引起争议。stable 团队使用 "Fixes:" tag 来挑选那些没有被明确标记为 stable 更新的 patch 的标志。4.4.x 系列包含了 7629 个带有这种 tag 的补丁，这仍然只占总数的 40%，所以这个 tag 也不是一个强有力的指标。stable 团队正在选择那些看起来像是 bug fix 的 patch，哪怕并没有进行明确标记。
Regressions and overall conclusion
不过，Fixes: 标签有了一个有趣的用途，就是用它们来判断是否其 fix 了在 stable 版本中在其之前合入的其他 patch。换句话说，一个带有 Fixes:标签的补丁是否修复了一个在 stable 系列中引入的错误？每一次出现这样的情况都表明在稳定版更新中出现了一次 regression 时间，而这正是稳定版内核所要竭力避免的。
在 4.4 稳定版系列中，有 1309 个 patch 包含了 Fixes：标签，并且指向的是稳定版系列中较早出现的提交。在这些 patch 中，有 310 个 patch 是在同一个稳定版本发布周期内合并的，这些 bug 从未被发布给外界，因此不应该被算作 regression 问题。而有些补丁需要多次 fix，也不应该被多次重复计算进来。过滤掉这些 patch 后，剩下 884 个 patch （占总数的 4.7% ），这是在 stable 更新过程中引入的 regression 问题。当然，这些 regression 中许多可能都从未被用户注意到，但其中有几个是挺严重的问题。
得益于这所有工作，4.4 内核用来支持了大量的设备。它是安卓 7 到 9 版本中所允许使用的内核版本之一，而且毫无疑问，尽管现在已经结束了后续支持服务，但它仍会在很多设备上继续运行。数以百万计的人会受益于 stable-kernel 维护者（以及所有帮助过他们的人）的这些工作。很难给这项工作具体量化成价值多少美元，但可以肯定的是一定数额巨大，它是对整个世界的一个重要礼物。
自由软件社区经常展现出的效果是它更善于制造一个软件，而不是长期支持这个软件。这种长期支持的任务经常是那些希望从工作中获得报酬的项目提供者做得更加好。不过，4.4.x 内核已经表明，当内核社区下定决心要完成某个任务时，它确实能够提供整整六年的支持。stable 团队挑选 patch 的方法尽管是有争议的，而且不管后续策略变成什么样子都可能永远仍然有争议，但是这个结果显然是非常棒了，足以建立起一个扩展开来的生态系统。基本上不会有什么争议，人们在这方面的努力完全是一个重大成功。
