shi*_*ish 30 linux kernel git history
我们都知道 Linus Torvalds 因为 Bitkeeper 的问题创建了 Git。不知道（至少对我而言）是，在那之前如何跟踪问题/故障单/错误？我试过了，但没有得到任何有趣的东西。我能够就该主题进行的唯一讨论是Linus 对使用 Bugzilla 的担忧。
推测： - 人们在初始阶段跟踪错误的最简单方法是将票放在自己的分支中，但我确信这不会随着噪音超过好错误而迅速扩展。
我见过并使用过 Bugzilla，除非您有时知道正确的“关键字”，否则您会被难住。注：我在最初几年（1991- 1995年），它们如何特别感兴趣用于跟踪问题。
我确实查看了两个线程，“内核 SCM 传奇”和“琐事：git 何时自托管？ ”但是这些都没有提到早期内核的错误跟踪。
我四处搜索，但没有找到 1991-1992 年存在的任何 FOSS 错误跟踪软件。Bugzilla、Request-tracker 和其他工具出现得更晚，所以它们似乎已经过时了。
期待更清晰地了解过去的事情是如何完成的。
小智 20
一开始，如果您有什么要贡献的（补丁或错误报告），您可以将其邮寄给 Linus。这演变成将其邮寄到列表（linux-kernel@vger.rutgers.edu之前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 README 中找到有趣的事情之一：
- 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.
mr.*_*tic 15
这些流程使用了新闻组 (USENET) 和（主要是）电子邮件。一个错误“存在”作为一个线程，在主题中放置“ [BUG REPORT]”或“ LINUX BUG REPORT”是一种常见的约定。没有错误 ID。鉴于典型的用户群，错误报告通常带有补丁。使用了一种被遗忘已久的软件工具：（ibug见下文），除了diff+ patch。
从Linux 安装和入门（1994 年 1 月，v2.0 存档副本） >
Run Code Online (Sandbox Code Playgroud)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 年 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 很少，大部分都在新闻组或通过 Linus 解决，然后我才能积累和发布。:) 简而言之：如果 Linux 或 Linux 移植软件中存在错误，通常会在下一个补丁级别或版本中修复。
有“linux-kernel”电子邮件列表（在原始版本上运行vger）、新闻组 alt.os.linux，然后是 comp.os.linux（在 1993 年迅速分裂为一个层次结构）。
这个来自 comp.os.linux 的早期 Linux 常见问题解答 (v1.11 Nov 1992)也建议直接向 Linus 发送电子邮件。
1992 年，Matt Welsh（Running Linux、Linux Bible、TLDP）宣布ibug协助生成通过电子邮件发送的错误报告（具有讽刺意味的是，当时你无法在 Linux 上运行它，因为它缺乏足够的网络来发送电子邮件）。
电子邮件错误报告模板linux.temp也定期发布在 comp.os.linux 上，错误报告的更新linux.fix.temp有一个更新模板。
还有一个补丁存储库 (FTP)，据我所知，这主要是（并非专门）用于为移植到 Linux 的程序提供补丁。
内核源代码的 CVS 副本很常见，我能找到的最早的是 Dirk Steinberg 的，来自 kernal-0.99.14 时代。我能找到的第一个公告是 1993 年 1 月在 linux-activists 上发布的。您仍然可以找到存档副本 (1994)。Dirk 还在 CVS 中维护了 cvs 二进制文件和 libc 源代码。
CVS 不是用来跟踪当代意义上的错误，一些开发人员更喜欢使用它，并且补丁经常以 cvs 生成的差异的形式提交。
大约在这个时候（1995 年 10 月），David S. Miller 开始将 CVS 用于 Linux 内核的 SPARC 端口（Linux/SPARC 端口）。到 1996 年 2 月，其他几个内核开发人员独立使用 CVS 来跟踪补丁，来自 linux-kernel这个线程和这个线程：Alan Cox、Stephen Tweedie、Kai Henningsen。（第二个帖子报道了 Russ Nelson 陈述了 Linus 对 CVS 的反感。）
1998 年 4 月，在 Linus 的第二个孩子出生后不久，CVS 的问题再次出现，从 linux-kernel 看到这个子线程（Linus 在那里直接重申了他对 CVS 的担忧）。
1997 年 12 月，Andrew Tridgell发布了 jitterbug，一个基于 Web 的错误跟踪器。到 1998 年 6 月，Alan Cox 在 linux-kernel上提倡“linux-patches”JitterBug 。据我所知，这是 Linus 和其他主要开发人员使用的第一个实际错误跟踪系统，遗憾的是“linux-patches”实例不再在线。
1998 年 9 月，Larry McEvoy首次在 linux-kernel 上推广了 bitkeeper。
到1999/2000 年，lkml FAQ开始提到（Q 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的Patchwork补丁跟踪器，这是一个与 SCCS 无关的基于 Web 的补丁跟踪器，它与邮件列表集成以跟踪补丁和跟进。它的使用一直持续到今天，在https://patchwork.kernel.org/上大约有 40 个以这种方式跟踪的列表，尽管并非所有列表都处于活动状态。
有用的参考：