从Linux2.4到2.6内核开发中的改进 （3）

追踪缺陷

自从 2.4 发布以来，对 Linux 内核的有组织测试最大的改进之一是缺陷追踪。过去，在 Linux 内核中发现的缺陷会报告给 Linux 内核邮件列表，报告给特定组件或者特定体系的邮件列表，或者直接报告给维护发现缺陷的那部分代码的个人。随着开发和测试 Linux 的人数的增加，这个系统的不足之处很快就暴露了出来。在以前，除非人们对缺陷的报告可以惊人地维持下去，缺陷经常被遗漏、遗忘或者忽略。

现 在，OSDL 安装了一个缺陷追踪系统（请参阅 参考资料 中的链接），来报告和追踪 Linux 内核的缺陷。系统经过了配置，这样当某个组件的缺陷被报告时，那个组件的维护者就会得到通知。维护者既可以接受并修复那个缺陷，或重新指定缺陷（如果最终确定实际上那是内核另外一部分的缺陷），也可以排除它（如果最终确定并不是真正的缺陷，比如错误配置的系统）。报告给邮件列表的缺陷还有丢失的 危险，因为越来越多的电子邮件涌向那个列表。然而，在缺陷追踪系统中，始终有对每一个缺陷及其当前状态的记录。

大量信息

在为将来的 2.6 Linux 内核进行开的过程中，除了这些自动化的信息管理方法之外，开放源代码社区的不同成员还收集和追踪了数量惊人的信息。

例 如，在 Kernel Newbies 站点上创建了一个状态列表，来保持对已经提出的内核新部件的追踪。这个列表包含了以状态排序的条目，如果它们已经完成了，则说明它们已经包含在哪个内核中，如果还没有完成，则指出还需要多长时间。列表上很多条目的链接指向大型项目的 Web 站点，或者当条目较小时，链接指向一个解释相应部件的电子邮件信息的拷贝。

同时，“post-halloween 文档”告诉用户即将到来的 2.6 内核有哪些可期待的东西（参阅 参考资料 中的链接）。post-halloween 文档的大部分讨论内容是用户需要注意的主要改变，以及需要更新的系统工具（为了利用它们）。关心这一信息人的主要是那些期望提前了解 2.6 内核中有哪些内容的 Linux 发行商，还有终端用户，这可以让他们确定为了能利用新部件是否有需要升级的程序。

Kernel Janitors 项目保持了（实际上现在还在保持）一个列表，内容是需要修复的较小缺陷和解决方法。这些缺陷解决方法中大部分是由于向内核打较大的补丁时需要改动很多部分代码而导致的，比如有些地方会影响设备驱动程序。那些新近从事内核开发的人开始时的工作可以选择列表中的条目，这样让他们可以通过小项目学习如何编写内核 代码，同时有机会为社区做出贡献。

还有，在另一个预发布的项目中，John Cherry 追踪了在对每个已经发布的内核版本进行编译时发现的错误和警告。这些编译统计数字随着时间的流逝一直持续下降，而且，以系统的形式来发布这些结果使得所取得的进展一目了然。在很多情况下，可以像使用 Kernel Janitors 列表一样来利用这些警告和错误消息中的一部分，因为编译错误通常是由小的缺陷引起的，需要一些努力去修复。

最后，还有 Andrew Morton 的“must-fix”列表。由于他已经被选定为 2.6 内核发布后的维护者，他运用他的特权概括地列出了那些他认为在最终的 2.6 内核发布前最迫切需要解决方案的问题。must-fix 列表中包含了内核 Bugzilla 系统中的缺陷，需要完成的部件，以及其他已知的问题，这些问题如不解决将阻碍 2.6 发布。这一信息可以帮助指明在新内核发布前还需要哪些步骤；对那些关心这一万众期待的 2.6 内核发布何时能完成的人来说，它还可以提供有价值的信息。

自从去年年底 2.6 内核发布以后，这些资料中有一些已经明显不再进行维护了。其他的相关工作在主要版本发布后仍未结束，还要继续进行后期的更新。有趣的是能看到哪些又被重新提起，有了哪些革新，我们又一次接近了一个主要发布版本。

结束语

多数人在考虑内核的一个新的稳定版本时，第一个问题通常是“这一版本中有什么新东西吗？”实际上除了一些新特性和修复之外，在幕后还有一个随着时间而不断改进的过程。

在 Linux 社区中，开放源代码开发日益兴旺。致力于 Linux 内核和其他方面工作的编码者之间联系是松散的，这就使得团队可以成功地适应变化。在许多方面，相对于已经完成的很多单个的改进和缺陷修复而言，Linux 的开发和测试方法 —— 尤其是这些方法随时间的推移得到了改进 —— 对新内核的可靠性影响更为深远。