Linux Kernel项目如何在早期阶段跟踪错误？

我们都知道Linus Torvalds是因为Bitkeeper的问题而创建了Git。（至少对我而言）不知道的是，直到那时如何跟踪问题/票证/错误？我尝试过，但没有得到任何有趣的东西。我唯一能就此主题进行的讨论是Linus与使用Bugzilla共享担忧的地方。

推测： -在最初阶段，人们追踪错误的最简单方法是将票放入其自己的分支中，但可以肯定的是，很快它不会因噪音超过好错误而扩大规模。

我已经看过并使用过Bugzilla，除非您有时会知道正确的“关键字”，否则您会很困惑。注意：我对早期（1991-1995年）如何用来跟踪问题特别感兴趣。

我确实看过两个线程，“ Kernel SCM saga ”和“ Trivia：git何时自托管？ ”，但是这些都没有提到早期的内核错误跟踪。

我四处搜寻，但无法获得1991-1992年间提供的任何FOSS错误跟踪软件。Bugzilla，Request-tracker和其他工具出现的时间要晚得多，因此它们似乎已经淘汰了。

关键问题

1. 那时候，Linus，子系统维护者和用户如何报告和跟踪错误？
2. 他们是否使用了某些错误跟踪软件，制作了一系列错误并手动提出了有关错误的问题和讨论（这样做会很昂贵且很痛苦）还是只使用电子邮件。
3. 后来，Bugzilla出现了（1998年第一版），这似乎是随后报告错误的主要方法。

希望对过去的事情有一个更清晰的了解。

一开始，如果您有贡献（补丁或错误报告），则将其邮寄给Linus。这演变为将其邮寄到列表（linux-kernel@vger.rutgers.edu之前kernel.org已创建）。

没有版本控制。Linus有时会在FTP服务器上放一个压缩包。这相当于一个“标签”。最初可用的工具是RCS和CVS，而Linus讨厌这些工具，因此每个人都只是邮寄补丁程序。（Linus解释了为什么他不想使用CVS。）

还有其他Bitkeeper之前的专有版本控制系统，但是基于志愿者的分散式Linux开发使其无法使用它们。随机发现漏洞的人，如果必须通过专有的版本控制系统，且许可证的起价为数千美元，则永远不会发送补丁。

Bitkeeper解决了这两个问题：它没有像CVS那样集中化，虽然它不是自由软件，但允许内核贡献者免费使用它。足够好一阵子了。

即使基于当今基于git的开发，邮件列表仍然是执行操作的地方。如果您想贡献一些东西，当然可以使用git进行准备，但是在合并之前，您必须在相关的邮件列表中进行讨论。Bugzilla的是那里看看“专业”，沉浸在从人谁不半生不熟的错误报告真正想参与进来。

要查看一些旧的错误报告说明，请获取历史Linux存储库。（这是一个git存储库，其中包含git存在之前的所有版本；由于它是从tarball重建的，因此每个版本大多数都包含一个提交）。感兴趣的文件包括README，MAINTAINERS，和REPORTING-BUGS。

您可以在Linux-0.99.12自述文件中找到有趣的事情之一：

 - if you have problems that seem to be due to kernel bugs, please mail
   them to me (Linus.Torvalds@Helsinki.FI), and possibly to any other
   relevant mailing-list or to the newsgroup.  The mailing-lists are
   useful especially for SCSI and NETworking problems, as I can't test
   either of those personally anyway.

流程使用新闻组（USENET）和（主要）电子邮件。一个常见的约定是，“存在”一个错误作为线程，在主题中放入“ [BUG REPORT]”或“ LINUX BUG REPORT”。没有错误ID。给定典型的用户群，错误报告通常带有补丁。ibug除了diff+ 以外，还使用了一种被人们遗忘的软件工具：（见下文）patch。

从Linux安装和入门（1994年1月，v2.0归档副本） >

2.6  The Design and Philosophy of Linux

 When new users encounter Linux, they often have a few misconceptions and
 false expectations of the system. Linux is a  unique  operating  system,
 and  it is important to understand its philosophy and design in order to
 use it effectively.  Time enough for a soapbox. Even if you are an  aged
 UNIX guru, what follows is probably of interest to you.

     In  commercial UNIX development houses, the entire system is devel-
 oped with a rigorous policy of quality assurance,  source  and  revision
 control systems, documentation, and bug reporting and resolution. [...]

     With  Linux,  you  can  throw  out  the entire concept of organized
 development, source control systems, structured bug reporting,  or  sta-
 tistical  analysis.   Linux  is,  and more than likely always will be, a
 hacker's operating system.(4)

                   [...]  For the most part, the Linux community communi-
 cates via various mailing lists and USENET newsgroups. A number of  con-
 ventions have sprung up around the development effort: for example, any-
 one wishing to have their  code  included  in  the  ``official''  kernel
 should  mail it to Linus Torvalds, which he will test and include in the
 kernel [...]

1992年

这是1992年12月（0.98.6）在comp.os.linux上的错误报告和修复：https ://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion

很早就出现了一个邮件列表ML-Linux的错误（1992/1993），从这个早期的常见问题在Slackware的 1.01分配：

VI.01）似乎$＃@！在Linux上移植无法正常运行，如何报告错误？

[...]请注意，我的“ ml-linux-bugs@dg-rtp.dg.com”错误报告列表已被淘汰。事实证明，Linux的bug很少，在我积累并发布之前，大多数bug已在新闻组或Linus上得到解决。:)简而言之：如果Linux或Linux移植的软件中存在错误，通常会在下一个补丁程序级别或版本中修复。

有一个“ linux-kernel”电子邮件列表（在原始上运行vger），新闻组alt.os.linux，然后是comp.os.linux（在1993年迅速拆分为一个层次结构）。

这个来自comp.os.linux的早期Linux FAQ（v1.11，1992年11月）也建议直接通过电子邮件发送Linus。

1992年，Matt Welsh（正在运行Linux，Linux Bible和TLDP）宣布ibug协助生成电子邮件错误报告（具有讽刺意味的是，由于当时Linux缺乏足够的网络来发送电子邮件，因此您当时无法在Linux上运行它）。

电子邮件错误报告模板linux.temp也定期发布在comp.os.linux上，错误报告的更新linux.fix.temp具有更新模板。

据我所知，这里还有一个补丁库（FTP），主要（不是唯一）用于移植到Linux的程序的补丁。

1993-1994

内核源代码的CVS副本很常见，我最早可以找到内核时代0.99.14时代的Dirk Steinberg的副本。我可以找到的第一个公告是1993年1月发布的关于Linux-activists的。您仍然可以找到存档副本（1994）。Dirk还在CVS中维护了cvs二进制文件和libc源代码。

CVS并不是现代意义上的跟踪错误，一些开发人员更喜欢使用它，并且补丁通常以cvs生成的差异形式提交。

1995-1996

大约在这个时间（1995年10月），David S. Miller开始将CVS用于Linux内核的SPARC端口（Linux / SPARC端口）。到1996年2月，其他几个内核开发人员都独立地使用CVS来跟踪补丁，从linux内核到该线程以及该线程：Alan Cox，Stephen Tweedie和Kai Henningsen。（第二个线程报道了Russ Nelson陈述了Linus对CVS的第一手厌恶。）

1997-1998

1998年4月，在Linus的第二个孩子出生后不久，CVS的问题再次出现，从linux内核中看到了这个子线程（Linus在此直接重申了他对CVS的关注）。

1997年12月，Andrew Tridgell 发布了基于网络的错误跟踪程序jitterbug。到1998年6月，Alan Cox在Linux内核上倡导了“ Linux补丁” JitterBug 。据我所知，这是Linus和其他主要开发人员使用的第一个实际的错误跟踪系统，遗憾的是“ linux-patches”实例不再在线。

1998年9月，Larry McEvoy 首次在Linux内核上推广bitkeeper。

1999年及以后

在1999/2000年，lkml FAQ开始（第1-16个问题）引用（原始）vger上的CVS树。当时由Andrew Tridgell维护。

到2001年12月，Jitterbug不再受欢迎，请参阅此linux-kernel 线程，Linus，Alan Cox和许多其他人参与讨论原因。

到2002年1月，Linus开始对bitkeeper（已经由PowerPC Linux内核团队使用）感兴趣。

2002年2月，Linus开始将Bitkeeper用于2.5开发树。

在2002年11月，OSDL 宣布为2.5树托管Linux Bugzilla 。（如果您尚未阅读问题中的bugzilla链接，请立即阅读，其中包含老式的Linus咆哮声）。

2005年4月，Linus宣布离开BitKeeper，大约在他第一次提到git名字时。在git具备自我托管能力之后不久，Linus停止使用BitKeeper并开始对内核使用git。

在2008年12月，宣布了针对Linux内核的Patchwork补丁跟踪器，这是一个与SCCS无关的基于Web的补丁跟踪器，与邮件列表集成以跟踪补丁和后续操作。直到今天，它的使用仍在继续，在https://patchwork.kernel.org/上大约跟踪了40个列表，尽管并非全部处于活动状态。

参考文献

有用的参考资料：

• 分布式工作的实质：Linux内核的案例（Jae Yun Moon，Lee Sproull） http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710（2000年11月）
• 报告Linux错误的准则（1992年7月） http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
• Kenneth R. Saborio的重要Linux帖子/电子邮件的存档：http : //www.informatica.co.cr/linux/index.htm（1991-2005）
• 从今天（2014年11月）到1995年的linux-kernel存档 http://lkml.iu.edu/hypermail/linux/kernel/ （不幸的是，第一封电子邮件来自1995年6月，管理员Chris Dent宣布他早些时候已丢失档案...） LKML档案只能追溯到1996年
• 来自tsx11的linux-devel 1993-1994的片段 http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux- devel / （忽略URL和文件中的日期）
• 版本管理工具：Linux内核，Sjaikh和Cornford 中的CVS到BK（大约2003年）
• 另请参阅此Hacker News主题（2015年3月），作为git十周年：https：//news.ycombinator.com/item？ id = 9263336

我可以告诉我们如何针对git自身的开发处理错误报告。

他们不使用任何错误跟踪软件。在开发邮件列表中报告并讨论了错误。这可能令人惊讶，但效果很好。

使用某些错误跟踪软件的问题或建议经常会出现，因此您可以通过搜索git邮件列表档案了解很多有关此问题的建议。

这与“我们还没有找到足够好的Bug跟踪器”有关；
但这也不是关于“我们有一个更好的方法”。

使用这种方法，项目或子项目的维护者（例如首席开发人员）在开发列表的非正式主持人中扮演着重要的角色。
处理错误是其中的一部分，用这种方式管理错误似乎并不是一件容易的事。当然，这取决于该职位人员的技能。

该方法最正式的部分是每周状态摘要消息。
它把当前在各个分支上发生的事情列为短项。有关git开发的示例，请在新闻组中通过gmane.comp.version-control.git镜像邮件列表进行查看：git.git的内容

我可以肯定地说：如果您有一位擅长于此的维护人员，那么它的工作效果非常好。
例如，如果引入错误跟踪器对实现的功能和质量产生积极影响，即使是在长期摊销变更开销之后，我也会感到非常惊讶。

对于Linux内核，直到今天为止，它与git的操作类似。
Linux内核开发的开发邮件列表当然很重要。但这不是像git这样的中心位置列表。副主题有单独的列表，例如文件系统或网络。
由于存在不同的主题，这些主题大部分由不同的开发人员处理，因此某些小组可能会在其小组本地使用工具。