Analyzing kernel email

原文来自：https://lwn.net/Articles/804511/

过去几年，有不少针对kernel开发过程中的email进行分析，因为email是Linux kernel开发流程的基础。分析email的原因有很多，可以把合入mainline的patch的其他信息对应起来，分析他们经过了哪些过程。在10月底法国里昂矩形的2019 Embedded Linux Conference Europe (ELCE)上，有三位研究者汇报了他们对kernel emal的一些分析信息。

演讲文档里有4位作者，其中一位没能赶到ELCE。这三位演讲者是雷根斯堡应用技术大学的Ralf Ramsauer，埃朗根纽伦堡大学的Sebastian Duda，以及来自慕尼黑的德国西门子公司Wolfgang Mauerer。未能参会的是Lukas Bulwahn，他是出于兴趣参与了Linux基金会的ELISA Project，主页是在BWM公司。这个演讲也证明，内核社区一直是研究者的一个观察对象。

Development process

Ramsauer指出这个俺就的目标是“定型评估Linux kernel开发流程”。社区内外都有不少人有动力做这个研究，他个人的兴趣是希望能写论文从而完成博士毕业（开玩笑吧）。还有一些对安全特性非常敏感的开发领域，包括汽车行业和工业界设备供应商，也对此非常感兴趣。安全方面获取认证的流程，要求要有文档规范过的开发流程，因为Linux开发流程并不受这些设备供应商的控制，所以他们顶多只能把现有的开发流程记录下来。除此之外，他们在使用的一些技巧，也可以用来监测Linux等项目是否在健康发展，正如CHAOSS project所做的那样。

近期在内核社区内部也有不少声音在推动要能跟踪patch的开发流程。人们提出要在patch里面增加change ID，也是希望用来在不同阶段跟踪patch。提出的方案很多，例如加个Message-ID，不过目前还没有一个kernel内部统一的方式。社区希望能找个方案，要能避免维护这些ID所耗的精力。

这个问题，主要来自于，目前mailing list上的讨论，与git仓库里的commit，目前是完全割裂的。他介绍了一下通常一个patch的生命周期。首先是开发过程，这个时候它通常是在某个Git分支上面；接下来这个patch会出现在一些mailing list上进行review；review反馈需要再修改这个patch，然后重新发出来，这个流程会持续多次；最后，patch被接受合入。

每一次发出这个patch set，有个Message-ID可以把所有的评论和讨论都跟它关联起来，不过不幸的是每一轮讨论都有一个不同的Message-ID。每版patch又有不同的Git commit hash值，这里Message ID和commit hash可能是个多对多的映射关系，因此需要有个工具来从mailing list和Git仓库里面把这个映射关系提取出来。

他们有个工具Patch Stack Analysis (PaStA)可以完成这个工作。此前这个工具是用来监测多个分支上的相似patch的，这样就可以良华分析那些out-of-tree项目（例如vendor kernel，realtime patch）有多少工作推送到upstream上了，后来工具被扩展出来可以分析mainling list。

他举了一个例子，展示他们是如何处理两个patch，认定他们非常类似。这些patch经过tokenized过程，然后评估词语差距（string distance measurement），打出一个评分来说明他们有多相似。如果分数超过标准，就认为这两个patch是相关的，然后创建一个相似图（similarity graph），最终跟git里的patch匹配起来。可以直接看他们的pdf来深入了解这里的技巧。

用来分析的Git数据很容易得到，直接clone过来就好。不过mailing list数据不是很容易拿到。几年之前的数据，他们都是用Gmane的数据，不过2016年之后这个服务就不台可靠了。lore.kernel.org也有很多数据，甚至有1996年的，不过它并未包含所有的mailing list，并且它有一些数据是从Gamen导入的，导入时没有处理好一些header信息，因此比较难用。

于是，他们开始在5月份来自己搜集了大概200个kernel mailing list。这个过程中，他们和其他进行email分析的人一样，碰到了同样的问题：email里面有各种各样的麻烦。包括语言编码错误，日期错误，Message-ID格式化出错，等等。等这些数据全部清理完毕，才开始进行分析。

Some results

Duda接下来介绍了他们分析后得到的一些信息。他们分析了mainline中的大概61万个commit，大概是从v2.6.39 tag以来的。还分析了lore.kernel.org上的大概3百万封邮件，大概选取了34个mailing list，从2011年5月一直分析到2018年底。不过这3百万封邮件里面并不是都是patch，删掉之后就还剩下115万封patch邮件了。也不是所有patch都能合入kernel的，此外，还有不少邮件是来自邮件机器人的，还有pull request，stable reviews，等等。最终，他们刷过之后还剩大概80万封邮件，这些都是人们提出来希望合入mainline的patch。他们的分析夜都是基于这组数据。

首先他们想看看是否能看出哪些子系统现在没有人维护了，分析方法就是查看哪些patch在mailing list上直接被忽略了。不过最后结果表明这么分析得不出正确结果。不过在这个过程中他们看到一些其他的有趣数据。首先他们定义了一下“被忽略”的标准，就是在这个讨论邮件中除了作者以外没有其他人回复过，并且patch没能被upstream接受，并且投到其他kernel版本的所有类似的patch都被忽略掉了。

基于这个标准得出，有2.5%的patch是被忽略掉的。有趣的是，这个数字是在不断降低的：2011年是3.9%，2015年是2.1%，2018年则是1.6%。2016年的时候有一个高峰，因为当时有一个1300个patch的提交，不出意外这个就被忽视了，把这个去掉之后，矫正过的数据看起来就很整齐了。

看起来差不多每周都有30~50个patch会被忽略掉，不过每周合入的patch其实一直在上升，因此百分比就在走低了。在Linux Plumbers Conference (LPC）会议上，有些maintainer就希望找到一个方法能了解他们忽略掉了多少patch，Duda也就针对这个问题对某几个mailing list进行了一下独立分析。

他展示了4幅图，分别是linux-arm-kernel, linux-mips, linux-wireless, netdev这几个mailing list。很明显的能看到它们忽略的patch数量都很稳定。这个数字在4个mailing list上都很小，大概每周10个以内。尽管越来越多的patch提交出来，不过这个数字一直保持稳定。

随着时间推移，linux-kernel-arm的每周patch数量从150变到了700，不过同时忽略的patch仍然是每周不到10个。这个数据在多数mailing list上都是如此，只有少数有例外。他们选了linux-kernel-arm和linux-kernel-mips，因为这两个都是架构相关的，不过Arm的list在过去几年大幅增长，而MIPS则基本一直比较平稳。linux-wireless和netdev也差不多如此，不过linux-wireless这几年开始有些下降了。

Ramsauer说他们还做过一个分析，就是patch被忽略的概率，是否跟它们提出来时的开发周期节点有关。不过分析下来，patch被忽略这件事跟它提出的开发周期的节点其实没有太大关系。不过如果patch是在merge window时提出的话，那么确实被忽略的概率要高那么一点点。

Off-list patches

在这个过程中，他们也还发现了一些没有经过mailing list的patch，这些patch包含在Linus Torvalds的Git tree里，不过在此之前并没有在public mailing list上出现过。他们也分析了一下5.1 kernel逐步稳定的过程，也就是从v5.1-rc到v5.1的过程中，有大概1800个commit。他们拿这些commit在mailing list里面查找，发现有60个是没在mailing list里面出现的。其中一些是由于他们工具问题报出来的，不过人工检查之后，看到确实有24个是off-list patch。

其中一些是revert，确实在mailing list上讨论过要做revert，不过revert patch本身并不会出现再mailing list上。还有一些是maintainer自己做的各种fixup，从来没有经过讨论。有一些子系统的maintainer经常会有off-list patch。此外，当然也还有一些security fix，它们是经过了一些未公开的讨论来决定合入的。例如，Greg Kroah-Hartman的 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.4-rc7&id=c7084edc3f6d67750f50d4183134c4fb5712a5c8 这个commit就从来没有在公开的mailing list上讨论过。他们询问过Greg Kroah-Hartman，得知这个patch是在一个小范围的kernel security mailing list里讨论决定的。可以看出，这种分析方法能够帮助找到一些尚未被公众知晓的security fix。

有一些听众想知道那些子系统会经常有off-list patch，不过这几位研究者不希望直接指出来。其他人其实也可以做同样的分析，得出同样的结论。很明显，这种off-list patch今后会很容易被发现。

Mauerer在总结时说，这类数据分析并没有得到资助，无论是工业界还是学术界的都没有。学术圈通常并不是很重视在ELCE上展示这些结果，而是会喜欢展示在论文小范围评审的过程中，尽管这时候的听众可能都是些一辈子都不会提交一个kernel patch的人。他希望今后有更多的公司和组织可以考虑来资助这方面的研究。

[I would like to thank LWN's travel sponsor, the Linux Foundation, for travel assistance to attend Embedded Linux Conference Europe in Lyon, France.]

全文完

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

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议修改再创作～

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～