https://lwn.net/Articles/738216/ @夷则

关于 "Regression" 这个词的翻译,笔者目前倾向于不翻。软件的 "Regression" 缺陷一般是指老版本中正常,然而在新版本中才出现的BUG;对应的测试被称为 "Regression Testing",这个词有公认的译名叫做“回归测试”,然而如果把 "Kernel Regressions" 翻译为“内核回归”或者“内核回归缺陷”,总是觉得不够信雅达,因此基于阅读习惯,本文暂时还是不翻译 "Regression" 这一词汇。 

书接上文,几天前的内核峰会上讨论过一次 Kernel Regression 的跟踪,几天后的 Maintainer 大会上,又被搬出来讨论了。跟踪 Kernel Regression 在内核中一直是个大老虎 ,问题一直很多。Leemhuis 就折腾了很久,但是最后这块骨头发现比他想象中更难啃。他认为最主要的问题在于,没人告诉他内核里有多少没解决的 Regression, 也不知道这些问题当前解决到什么进度了,他只好去邮件列表里挖各种信息。

首先他提出来的是找个方法来给 Regression 做一些标记,他提了几个东西,Bugzilla, 专门的邮件列表,以及完善文档来告诉大家怎么用这些系统。

然后大伙儿聊了一会儿 Bugzilla。Bugzilla 用于追踪的初衷是好的,但是如果报 bug 的人不够专业,无法提供有效信息,效果就大打折扣,有时候一个A问题报出来查到最后结果会变成B问题;另外还有好多人不会用 Bugzilla。看起来 Bugzilla 是一个专业性要求很强的工具,没有太多背景知识很可能玩不转。

于是话题又转向了没有经验的用户的问题,有人连编内核都磕磕绊绊,怎么指望他们帮忙分析问题,或者修 bug。于是 Greg KH 提出关于完善入门文档的事情,接着大伙儿又讨论邮件列表报 bug 还是 Bugzilla 报 bug 孰优孰劣的问题,猜想场面一度十分混乱。

大伙儿讨论着,又回到了 lkml 的问题,这个邮件列表简直就是个黑洞,经常有问题发出来因为没有发给对的人,所以问题没人理,或者 Patch 被无视。有人提出来搞个 bot 自动回复一下,告诉发送人这个问题可以抄给哪个对的人,这是一个好想法。

接下去又讨论到 "Regresion" 这个词的适用性问题,有些子系统 Maintainer 很抗拒承认某些 bug 是 Regression,因为这样他就得高优先级解决;而有些人很喜欢把有些 bug 标记为 Regression,这样如果 rc 窗口比较晚了,Regression 的修复会更容易拿到 rc tree 的门票,这两种情况显然都是不合适的。Linus 跳出来谴责了一下前面这类 maintainer,估计是觉得人家太懒了。

Linus 教育大家说,前面几位同学觉得 Regression 的跟踪太痛苦了,是因为干这活儿的人,Wysocki 也好 Leemhuis 也罢,都是单兵作战。从这个出发点来说,写文档写脚本的帮助都很有限,真正有帮助的是发动更多的人参与进来。所以他是支持用 Bugzilla 的,因为这是一个协作平台,虽然这玩意儿现在一塌糊涂。

后面的讨论还包括一些特定硬件上的 Regression,一般人测起来比较困难;有人只能用 mock 的方式来测,单元测试也只能覆盖部分内容;还有人提到可以统计统计哪些子系统更容易出 Regression,然后专项改进,然而在结束的时候大家都不知道哪个子系统更容易出 Regression。 (谁愿意承认呢?)

	    翻到这里,笔者想起来当年在 Red Hat 当 Kernel QE 的日子,当时 Red Hat Kernel QE 团队对于追踪 Kernel Regression 的策略主要是这么几种:

	    1. 维护各种内核测试套件,出一个新版本就进行一遍回归测试,从覆盖率上来保证尽可能挖掘到更多的 Regression;
	    2. 去挖各种邮件列表里大伙儿提到的 Regression 报告,写脚本放到组里的回归测试集中;
	    3. 每人包一块子系统的测试,守着 Bugzilla,优先照顾 Regression,针对 Regression 一定要想办法把测试脚本化。

	    这些方法其实前面讨论都提到了,毕竟是商业化公司,讨论中很多担心的点,比如提 bug 的人的素质问题,比如挖邮件列表信息的动力问题,在这里都不是问题,毕竟有人付钱雇ä½ 干活儿了,肯定有动力,对吧。