关于 "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 的人的素质问题，比如挖邮件列表信息的动力问题，在这里都不是问题，毕竟有人付钱雇ä½ 干活儿了，肯定有动力，对吧。