LWN: 5.12 开发周期的统计数据！

关注了就能看到更多这么棒的文章哦～

Some 5.12 development statistics

By Jonathan Corbet
April 26, 2021
DeepL assisted translation
https://lwn.net/Articles/853039/

5.12 kernel 最终发布之时，这个开发周期中已经有 13,015 个 non-merge changeset 被合入 mainline 了。这导致 5.12 是 5.6（2020 年 3 月底发布）以来最慢的一个开发周期。在 5.12 中仍然有大量开发工作得以完成。请继续阅读 LWN 传统的分析内容来了解这些工作都是来自哪里，以及如何进入 kernel。

5.12 中有 1.873 位开发者贡献了 patch，其中 262 位是首次贡献者。这些数字都在正常水平，尤其是考虑到这次开发周期中的内容偏少。最活跃的 5.12 开发者们是：

与 5.11 周期类似，Lee Jones 贡献了最多的 changeset，因为他仍在继续对编译时以及 docs-build 的 warning 进行 fix。Chris Wilson 在开发的是 Intel i915 graphics driver。Pavel Begunkov 则主要在 io_uring 子系统里工作，Vladimir Oltean 对 network 子系统进行了许多改进，Christoph Hellwig 主要继续在清理 block layer 以及 filesystem 里的代码。

Arnd Bergmann 删除了若干已经废弃的体系架构，以及它们特有的驱动程序，因此凭借删除掉的代码行数得以在"lines changed"这一列登顶。Po-Hao Huang 贡献了 8 个 patch，主要都是在更新一些机器生成的 table。Viresh Kumar 删除了已经不再使用的 "oprofile" 这个 profiling 机制，Maximilian Luz 增加了对 Microsoft Surface 设备的支持，Andy SHevchenko 删除了一些不再需要的 Intel 驱动代码。

Report, test, and review credits

kernel 社区除了代码以外，还需要很多其他的贡献。包括需要人们报出问题，也需要人们进行测试以及 review 代码。因此内核开发者们也通过在相关的 patch 上加上 tag 来对这些贡献者表示认可。在 5.12 中修复的 bug 的报告者之中，最活跃的是：

这里我们看到自动测试系统的贡献不断提升，我们也希望这些系统能在有 bug 影响到最终用户之前就先报告出来。

这一轮中的最活跃的 tester 和 reviewer 人员是：

Tested-by 这一列中最上面的几位，看起来基本上都是在对他们的同僚提供的 patch 进行验证，这种情况可能更多的时候是不会打上 tag 的。Matt Merhar，Nicolas Chauvet，Peter Geis 验证的 patch 数量都差不多，这并不是一个巧合。实际上他们三位经常是在测试来自同一位作者的同一批 patch。而 Reviewed-by 这一列情况则更加分散，其中主要是那些活跃的维护者，以及其他一些经常投入时间来 review patch 的开发者。

Employer support

5.12 的开发工作中我们能识别出来的有 211 个公司和组织，比起上一版本来说略有下降，但是这也跟 5.12 版本中相对偏少的 patch 数量是吻合的。这一次最活跃的公司是：

不出意料，这些数字跟 5.11 的时候差不多，也跟之前很多时候的差不多。最大的变化是 Linaro 这次大刀阔斧的删除代码，因此得以登顶“lines changed” 这一列。

The path into the mainline

虽然 Linus Torvalds 最终负责把这里提到的所有 patch 都合入 mainline，不过他直接处理的 patch 其实很少，目前所有 patch 基本上都是经过至少一个子系统的维护者的 git 仓库的。根据 patch 合入 mainline 的路径，可以生成一个能反映我们社区是如何一起工作的示意图。不知道这张图跟我们经常描述 kernel 社区的层级结构图在多大程度上是吻合的？

每一封电子邮件在发送者和接收者之间传递的时候通常都需要经过若干个服务器，每个服务器都可能添加一个"Recived" 邮件头来标记一下。而 Git commit 则不会记录它经过了哪些 Git 仓库。不过，在一批 commit 从一个仓库合入另一个 git 仓库的时候，会产生一个 merge commit，至少绝大多数时候都会生成。有些项目可能会对 merge commit 非常反感，因此要求利用 rebasing 和 fast-foward merge 来避免生成任何 merge commit。而 kernel 并不禁止 merge commit，于是绝大多数 pull 操作都会产生一个 merge commit。

Git 在创建这个 commit 的时候，会在 changelog 消息的开头位置记录一下是从哪个 git tree 合入过来的。假设 maintainer 保留了这个信息的话，这样就可以利用这个信息来分析这些 commit 都是从哪里来的了。很幸运，几乎所有 kernel maintainer 都会保留这部分信息。

这个 merge commit 还包含了用来对这组 commit 中头部的 commit 的 tag 进行签名的 GPG key。这也是一个有用的信息。理论上来说，所有的 pull request 都应该包含一个签名的 tag，从而确保相关的将要合入 mainline 的 commit 都是由可以识别出来的 kernel maintaner 来标记的 commit。实际上并不是所有的 maintainer 都会对他们的 commit 进行这样的签名操作。Torvalds 也没有强行要求从 kernel.org 上的各个 git 仓库中发起的 pull request 都要带有签名，不过对于来自其他地方存放的 git 仓库的 pull 请求通常都是要求有签名的。

treeplot 程序来自 gitdm 这组拼凑起来的数据分析工具，它可以搜集这些信息并生成图示。最终结果也提供在本文中了。这里的矩形代表了一个个 Git 仓库，箭头表示了 commit 的流向。每个箭头旁边的数字表示有多少个 commit 是经过这里来合入 5.12 的 kernel 的。黑色表示使用了签名过的 tag，红色表示没有签名。

这个图示的形状每一年都会发生一些变化，目前来说仍然有非常多的仓库直接由 Torvalds 合入 mainline，仍然是非常扁平化的结构，不过我们也开始看到经过中间层的 maintainer 的 commit 的数量也在增长。有些较大的子系统，比如 networking, graphics, Arm system 等，都是有多层的 maintainer 来提供 patch 的。流入 mainline 的 patch 中最多的一条路还是经过 networking 仓库的，在 5.12 中，这里有超过 2,400 个 commit 进入了 mainline。

并且 networking 的这些仓库也产生了数量最多的未对 tag 进行签名保护的 commit。这个情况也已经保持多年了。不过，在 126 个对 5.12 有贡献的 Git 仓库中，只有 15 个没有使用 signed tag 了，情况比起过去几年已经好了很多。不过，比较有意思的是这些未用签名验证技术的仓库中，有一个恰恰正是 crypto 仓库。

Torvalds 要求来自 GitHub 等其他 site 的 pull 都要提供 signed tag，不过可以看到其他一些 maintainer 并未这么做。因此，有一些来自公共网站的未被签名的 pull request 仍然合入了 mainline kernel，就是来自这些中间 maintainer。

不过，从这个最终生成的图片看来，我们的社区尽管有许多困难，但是仍然将大量的改动采用了可靠的、可预期的方式合入进来。其他项目很少有既能保持我们 kernel 社区类似的规模，同时还能提供稳定可用的产出的。在撰写本文的时候，已经有 13,677 个 changeset 加入了 linux-nest，其中绝大多数都会进入 5.13，因此这个流程看起来并不会放缓。

更新：在本文初次公开之后，根据 Leon Romanovsky 的提醒，对公司相关的贡献数量有修改。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～