追踪缺陷
自从2.4发布以来,对Linux内核的有组织测试最大的改进之一是缺陷追踪。过去,在Linux内核中发现的缺陷会报告给Linux内核邮件列表,报告给特定组件或者特定体系的邮件列表,或者直接报告给维护发现缺陷的那部分代码的个人。随着开发和测试Linux的人数的增加,这个系统的不足之处很快就暴露了出来。在以前,除非人们对缺陷的报告可以惊人地维持下去,缺陷经常被遗漏、遗忘或者忽略。
现在,OSDL安装了一个缺陷追踪系统(请参阅参考资料中的链接),来报告和追踪Linux内核的缺陷。系统经过了配置,这样当某个组件的缺陷被报告时,那个组件的维护者就会得到通知。维护者既可以接受并修复那个缺陷,或重新指定缺陷(如果最终确定实际上那是内核另外一部分的缺陷),也可以排除它(如果最终确定并不是真正的缺陷,比如错误配置的系统)。报告给邮件列表的缺陷还有丢失的危险,因为越来越多的电子邮件涌向那个列表。然而,在缺陷追踪系统中,始终有对每一个缺陷及其当前状态的记录。
大量信息
在为将来的2.6Linux内核进行开的过程中,除了这些自动化的信息管理方法之外,开放源代码社区的不同成员还收集和追踪了数量惊人的信息。
例如,在KernelNewbies站点上创建了一个状态列表,来保持对已经提出的内核新部件的追踪。这个列表包含了以状态排序的条目,如果它们已经完成了,则说明它们已经包含在哪个内核中,如果还没有完成,则指出还需要多长时间。列表上很多条目的链接指向大型项目的Web站点,或者当条目较小时,链接指向一个解释相应部件的电子邮件信息的拷贝。
同时,“post-halloween文档”告诉用户即将到来的2.6内核有哪些可期待的东西(参阅参考资料中的链接)。post- halloween文档的大部分讨论内容是用户需要注意的主要改变,以及需要更新的系统工具(为了利用它们)。关心这一信息人的主要是那些期望提前了解 2.6内核中有哪些内容的Linux发行商,还有终端用户,这可以让他们确定为了能利用新部件是否有需要升级的程序。
KernelJanitors项目保持了(实际上现在还在保持)一个列表,内容是需要修复的较小缺陷和解决方法。这些缺陷解决方法中大部分是由于向内核打较大的补丁时需要改动很多部分代码而导致的,比如有些地方会影响设备驱动程序。那些新近从事内核开发的人开始时的工作可以选择列表中的条目,这样让他们可以通过小项目学习如何编写内核代码,同时有机会为社区做出贡献。
还有,在另一个预发布的项目中,JohnCherry追踪了在对每个已经发布的内核版本进行编译时发现的错误和警告。这些编译统计数字随着时间的流逝一直持续下降,而且,以系统的形式来发布这些结果使得所取得的进展一目了然。在很多情况下,可以像使用KernelJanitors列表一样来利用这些警告和错误消息中的一部分,因为编译错误通常是由小的缺陷引起的,需要一些努力去修复。
最后,还有AndrewMorton的“must-fix”列表。由于他已经被选定为2.6内核发布后的维护者,他运用他的特权概括地列出了那些他认为在最终的2.6内核发布前最迫切需要解决方案的问题。must-fix列表中包含了内核Bugzilla系统中的缺陷,需要完成的部件,以及其他已知的问题,这些问题如不解决将阻碍2.6发布。这一信息可以帮助指明在新内核发布前还需要哪些步骤;对那些关心这一万众期待的2.6内核发布何时能完成的人来说,它还可以提供有价值的信息。
自从去年年底2.6内核发布以后,这些资料中有一些已经明显不再进行维护了。其他的相关工作在主要版本发布后仍未结束,还要继续进行后期的更新。有趣的是能看到哪些又被重新提起,有了哪些革新,我们又一次接近了一个主要发布版本。
结束语
多数人在考虑内核的一个新的稳定版本时,第一个问题通常是“这一版本中有什么新东西吗?”实际上除了一些新特性和修复之外,在幕后还有一个随着时间而不断改进的过程。
| 论坛热门帖子: | [lch203] 写得蛮好的linux学习笔记(10-21) [黑马制造] 学习java的30个目标(10-19) [笑傲股林] 做测试半年了,有点迷茫,应该再学些什么提高自己的测试水平和测试能力呢?(10-19) [udp8589] 大家用google的来吱一声? 用百度的~~也来报道下?(10-18) [沂偌掳兆] 本人总结的一些认为C++比较经典的书籍,希望对大家有用(10-18) |
| TAG标签: | 进而 如何 内核 测试 可以 Linux 一个 缺陷 开发 发布 |
注册
个人空间
