☰

Linux 内核项目早期是如何跟踪错误的？

tag-icon • tag-icon linux kernel git history
Linux 内核项目早期是如何跟踪错误的？

我们都知道 Linus Torvalds 由于 Bitkeeper 的问题而创建了 Git。不知道的（至少对我来说）是，在那之前如何跟踪问题/票证/错误？我尝试过但没有得到任何有趣的东西。我能就这个主题进行的唯一讨论是这个Linus 分享了对使用 Bugzilla 的担忧。

推测：- 人们在初始阶段跟踪错误的最简单方法是将票放入其自己的分支中，但我确信很快就不会随着噪音超过好错误而扩展。

我见过并使用过 Bugzilla，除非您知道正确的“关键字”，否则您有时会被难住。笔记：我对早年（1991-1995）特别感兴趣，了解他们如何习惯于跟踪问题。

我确实看了两条线索，“内核 SCM 传奇“， 和 ”琐事：git 什么时候开始自我托管？” 但这些都没有提到早期的内核错误跟踪。

我四处搜寻，没有找到任何 1991-1992 年间出现的 FOSS bug 跟踪软件。 Bugzilla、Request-tracker 和其他工具的出现要晚得多，所以它们似乎已经被淘汰了。

关键问题

  1. 那么当时的 Linus、子系统维护者和用户是如何报告和跟踪 bug 的呢？
  2. 他们是否使用了一些错误跟踪软件，创建了错误分支并手动提交了有关其中错误的问题和讨论（这样做会很昂贵且痛苦），或者只是使用电子邮件。
  3. 很久以后，Bugzilla 出现了（1998 年首次发布），这似乎是事后报告错误的主要方式。

期待更清楚地了解过去的事情是如何做的。

答案1

一开始，如果您需要贡献一些东西（补丁或错误报告），您可以将其邮寄给 Linus。这演变成了将其邮寄到列表（在创建[email protected]之前）。kernel.org

没有版本控制。 Linus 有时会在 FTP 服务器上放置一个 tarball。这相当于一个“标签”。一开始可用的工具是 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 ([email protected]), 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.

答案2

这些流程使用新闻组 (USENET) 和（主要）电子邮件。 bug 作为线程“存在”，在主题中添加“ [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-bug(1992/1993)，从这里早期常见问题解答在里面斯莱克软件1.01发行版：

VI.01) 看来$#@!移植到 Linux 上无法正常运行，如何报告错误？

[...] 请注意，我的“[电子邮件受保护]“ bug 报告列表已经被淘汰了。事实证明，Linux 的 bug 太少了，其中大部分都在新闻组或通过 Linus 解决了，然后我才能积累它们并发布。:) 简而言之：如果 Linux 中存在 bug 或在Linux移植的软件中，它通常会在下一个补丁级别或版本中修复。

有“linux-kernel”电子邮件列表（在原始版本上运行vger）、新闻组 alt.os.linux，然后是 comp.os.linux（很快1993年分裂为等级制度）。

这早期 Linux 常见问题解答（v1.11 1992 年 11 月）comp.os.linux 还建议直接向 Linus 发送电子邮件。

1992年马特·威尔士(运行Linux,Linux圣经,TLDP）宣布ibug帮助生成通过电子邮件发送的错误报告（具有讽刺意味的是，当时您无法在 Linux 上运行它，因为它缺乏足够的网络来发送电子邮件）。

一封电邮错误报告模板linux.temp也定期发布在 comp.os.linux 上，并且错误报告的更新有更新模板linux.fix.temp。

还有一个补丁存储库 (FTP)，据我所知，这主要是（不完全是）用于移植到 Linux 的程序补丁。

1993-1994

内核源代码的 CVS 副本很常见，我能找到的最早的是 Dirk Steinberg 的，来自 kernal-0.99.14 时代。这第一个公告我可以在 linux-activists 上找到 1993 年 1 月的内容。你仍然可以找到存档副本（1994年）。 Dirk 还在 CVS 中维护 cvs 二进制文件和 libc 源代码。

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

1995-1996

大约在这个时候（1995 年 10 月）David S. Miller 开始将 CVS 用于 Linux 内核的 SPARC 端口（Linux/SPARC 端口）。到 1996 年 2 月，其他几位内核开发人员独立使用 CVS 来跟踪来自 linux-kernel 的补丁这个线程和这个线程：艾伦·考克斯、斯蒂芬·特威迪、凯·亨宁森。 （第二条线索报道 Russ Nelson 直接表达了 Linus 对 CVS 的厌恶。）

1997-1998

1998年4月，Linus的第二个孩子出生后不久，CVS的问题再次出现，从linux-kernel看到这个子线程（Linus 直接重申了他对 CVS 的担忧）。

1997 年 12 月，安德鲁·特里格尔发布了吉特巴舞，一个基于网络的错误跟踪器。到 1998 年 6 月，“linux-patches”JitterBug 已经被开发出来由 Alan Cox 在 linux-kernel 上提倡。据我所知，这是 Linus 和其他主要开发人员使用的第一个实际错误跟踪系统，遗憾的是“linux-patches”实例不再在线。

1998年9月，bitkeeper 首次在 Linux 内核上推广作者：拉里·麦克沃伊。

1999年及以后

经过1999/2000 lkml 常见问题解答开始参考（问题 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-kernel 已发布，这是一个与 SCCS 无关的基于 Web 的补丁跟踪器，它与邮件列表集成以跟踪补丁和后续补丁。它的使用一直持续到今天，大约有 40 个列表通过这种方式被跟踪https://patchwork.kernel.org/，尽管并非全部都是活跃的。

参考

有用的参考：

答案3

我可以说出错误报告是如何处理其自身开发的git。

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

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

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

通过这种方法，项目或子项目的维护者（例如首席开发人员）可以作为开发列表的非正式主持人发挥重要作用。
处理 bug 是其中的一部分，以这种方式管理 bug 似乎并不是一项简单的任务；这当然取决于担任该角色的人员的技能。

该方法最正式的部分是每周状态摘要消息。
它将各个分支当前正在发生的事情列为简短项目。有关 git 开发的示例，请参阅gmane.comp.version-control.git镜像邮件列表的新闻组：git.git 正在做什么

我可以肯定地说：如果你有一个擅长这方面的维护者，那么它会工作得非常好。
例如，我会非常如果错误跟踪器的引入对实现的功能和质量产生积极的生产力影响，甚至在摊销变更开销后的长期来看，我们会感到惊讶。


对于 Linux 内核，到目前为止，它与 git 的做法类似。
Linux 内核开发的开发邮件列表当然很重要。但它不像 git 那样以一个列表作为中心位置。有单独的子主题列表，例如文件系统或网络。
由于存在单独的主题，并且主要由单独的开发人员处理，因此某些组可能确实使用其组本地的工具。

相关内容