Linux Kernel – How Did the Project Track Bugs in the Early Days?

githistorykernellinux

We all know that Linus Torvalds created Git because of issues with Bitkeeper. What is not known (at least to me) is, how were issues/tickets/bugs tracked up until then? I tried but didn't get anything interesting. The only discussion I was able to get on the subject was this one where Linus shared concerns with about using Bugzilla.

Speculation: – The easiest way for people to track bugs in the initial phase would have been to put tickets in a branch of its own but am sure that pretty quickly that wouldn't have scaled with the noise over-taking the good bugs.

I've seen and used Bugzilla and unless you know the right 'keywords' at times you would be stumped. NOTE: I'm specifically interested in the early years (1991-1995) as to how they used to track issues.

I did look at two threads, "Kernel SCM saga", and "Trivia: When did git self-host?" but none of these made mention about bug-tracking of the kernel in the early days.

I searched around and wasn't able to get of any FOSS bug-tracking software which was there in 1991-1992. Bugzilla, Request-tracker, and others came much later, so they appear to be out.

Key questions

How did then Linus, the subsystem-maintainers, and users report and track bugs in those days?
Did they use some bug-tracking software, made a branch of bugs and manually committed questions and discussions on the bug therein (would be expensive and painful to do that) or just use e-mail.
Much later, Bugzilla came along (first release 1998) and that seems to be the primary way to report bugs afterwards.

Looking forward to have a clearer picture of how things were done in the older days.

Best Answer

In the beginning, if you had something to contribute (a patch or a bug report), you mailed it to Linus. This evolved into mailing it to the list (which was linux-kernel@vger.rutgers.edu before kernel.org was created).

There was no version control. From time to time, Linus put a tarball on the FTP server. This was the equivalent of a "tag". The available tools at the beginning were RCS and CVS, and Linus hates those, so everybody just mailed patches. (There is an explanation from Linus about why he didn't want to use CVS.)

There were other pre-Bitkeeper proprietary version control systems, but the decentralized, volunteer-based development of Linux made it impossible to use them. A random person who just found a bug will never send a patch if it has to go through a proprietary version control system with licenses starting in the thousands of dollars.

Bitkeeper got around both of those problems: it wasn't centralized like CVS, and while it was not Free Software, kernel contributors were allowed to use it without paying. That made it good enough for a while.

Even with today's git-based development, the mailing lists are still where the action is. When you want to contribute something, you'll prepare it with git of course, but you'll have to discuss it on the relevant mailing list before it gets merged. Bugzilla is there to look "professional" and soak up half-baked bug reports from people who don't really want to get involved.

To see some of the old bug-reporting instructions, get the historical Linux repository. (This is a git repository containing all the versions from before git existed; mostly it contains one commit per release since it was reconstructed from the tarballs). Files of interest include README, MAINTAINERS, and REPORTING-BUGS.

One of the interesting things you can find there is this from the 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.

Related Solutions

Is `cal` broken? What happened in September 1752

To trace the real story, try running man cal yourself:

The Gregorian Reformation is assumed to have occurred in 1752 on the 3rd
of September.  By this time, most countries had recognized the reforma-
tion (although a few did not recognize it until the early 1900’s.)  Ten
days following that date were eliminated by the reformation, so the cal-
endar for that month is a bit unusual.

Then, if your history is sketchy, continue with Wikipedia for information about the changes introduced by Gregorian Calendar and it's history of adoption in various parts of the world:

The Gregorian calendar reform contained two parts, a reform of the Julian calendar as used up to Pope Gregory's time, together with a reform of the lunar cycle used by the Church along with the Julian calendar for calculating dates of Easter.
[...]
In addition to the change in the mean length of the calendar year from 365.25 days (365 days 6 hours) to 365.2425 days (365 days 5 hours 49 minutes 12 seconds), a reduction of 10 minutes 48 seconds per year, the Gregorian calendar reform also dealt with the past accumulated difference between these lengths.
[...]
Because of the Protestant Reformation, however, many Western European countries did not initially follow the Gregorian reform, and maintained their old-style systems. Eventually other countries followed the reform for the sake of consistency, but by the time the last adherents of the Julian calendar in Eastern Europe (Russia and Greece) changed to the Gregorian system in the 20th century, they had to drop 13 days from their calendars, due to the additional accumulated difference between the two calendars since 1582.
[...]
Britain and the British Empire (including the eastern part of what is now the United States) adopted the Gregorian calendar in 1752, by which time it was necessary to correct by 11 days. Wednesday, 2 September 1752 was followed by Thursday, 14 September 1752.

By the time Unix came along and reset the worlds clocks to start at January 1st, 1970 there was nothing to be done about the whole mess except pick a date to show the reset on. Since the world adopted the current Gregorian calendar system at varying times in different countries, the exact time to make this correction is somewhat arbitrary.

If you ever have a reason to count dates going back that far in your software, you will run into much more significant issues than just that one reset! The history of calendaring is full of surprises!

What’s the difference between `Commit hash`, `Parent Hash` and `Tree hash` in git

Parent hashes:

$ git log --graph
*   commit c06c4c912dbd9ee377d14ec8ebe2847cf1a3ec7e
|\  Merge: 79e6924 3113760
| | Author: linjie <linjielig@gmail.com>
| | Date:   Mon Mar 14 16:02:09 2016 +0800
| |
| |     commit5
| |
| |     Merge branch 'dev'
| |
| * commit 31137606f85d8960fa1640d0881682a081ffa9d0
| | Author: linjie <linjielig@gmail.com>
| | Date:   Mon Mar 14 16:01:26 2016 +0800
| |
| |     commit3
| |
* | commit 79e69240ccd218d49d78a72f33002fd6bc62f407
|/  Author: linjie <linjielig@gmail.com>
|   Date:   Mon Mar 14 16:01:59 2016 +0800
|
|       commit4
|
* commit 7fd4e3fdddb89858d925a89767ec62985ba07f3d
| Author: linjie <linjielig@gmail.com>
| Date:   Mon Mar 14 16:01:00 2016 +0800
|
|     commit2
|
* commit 316dd3fb3c7b501bc9974676adcf558a18508dd4
  Author: linjie <linjielig@gmail.com>
  Date:   Mon Mar 14 16:00:34 2016 +0800

     commit1

$ git log --pretty=format:'%<(82)%P %s'
79e69240ccd218d49d78a72f33002fd6bc62f407 31137606f85d8960fa1640d0881682a081ffa9d0  commit5
7fd4e3fdddb89858d925a89767ec62985ba07f3d                                           commit4
7fd4e3fdddb89858d925a89767ec62985ba07f3d                                           commit3
316dd3fb3c7b501bc9974676adcf558a18508dd4                                           commit2
                                                                                   commit1

You can see commit4 and commit3 is parent of commit5, commit2 is parent of commit3 and commit4, commit1 is parent of commit2.

Tree hash:

$ git log --pretty=format:'%T %s'
f3c7cee96f33938631a9b023ccf5d8743b00db0e commit5
e0ecb42ae45ddc91c947289f928ea5085c70b208 commit4
d466aea17dc07516c449c58a73b2dc3faa9d11a1 commit3
b39f2e707050e0c5bbb3b48680f416ef05b179ba commit2
5706ec2b32605e27fa04cbef37d582325d14dda9 commit1

$ git cat-file -p f3c7ce
100644 blob 8bb2e871e94c486a867f5cfcbc6f30d004f6a9e5    dev
100644 blob 47f16c8e00adba77ec5c176876e99c8e9f05d69b    master

$ git cat-file -p 5706ec
100644 blob fc0bfde0d44bb4d6c7d27b6e587ebedd34ba5911    master

The command's function: Pretty-print the contents of <object> based on it's type.

git cat-file -p

In git,all the content is stored as tree and blob objects, with trees corresponding to UNIX directory entries and blobs corresponding more or less to inodes or file contents. A single tree object contains one or more tree entries, each of which contains a SHA-1 pointer to a blob or subtree with its associated mode, type, and filename. Git normally creates a tree by taking the state of your staging area or index and writing a series of tree objects from it. Commit objects have the information about who saved the tree object, when they saved or why they were saved. This is the basic information that the commit object stores for you.

Conclusion:

Commit hash, Parent hash, Tree hash are all SHA-1. Commit hash and Parent hash is identical except Parent hash has child. Tree hash is represent a Tree object. Commit hash and Parent hash represent a commit object.