Wie hat das Linux-Kernel-Projekt Fehler in den frühen Tagen nachverfolgt?

Wir alle wissen, dass Linus Torvalds Git aufgrund von Problemen mit Bitkeeper erstellt hat. Was (zumindest für mich) nicht bekannt ist, wie wurden Probleme / Tickets / Bugs bis dahin aufgespürt? Ich habe versucht, aber nichts Interessantes bekommen. Die einzige Diskussion, die ich zu diesem Thema führen konnte, war die, in der Linus Bedenken hinsichtlich der Verwendung von Bugzilla äußerte .

Spekulationen: - Die einfachste Möglichkeit für die Leute, Fehler in der Anfangsphase aufzuspüren, bestand darin, Tickets in eine eigene Filiale zu stellen, aber ich bin mir sicher, dass dies ziemlich schnell geschehen würde, wenn der Lärm die guten Fehler überwunden hätte.

Ich habe Bugzilla gesehen und benutzt und es sei denn, Sie kennen die richtigen "Schlüsselwörter" zuweilen, wären Sie ratlos. HINWEIS: Ich interessiere mich speziell für die ersten Jahre (1991-1995) , in denen Probleme verfolgt wurden.

Ich habe mir zwei Threads angesehen, " Kernel SCM saga " und " Trivia: Wann hat git sich selbst gehostet? "

Ich habe mich umgesehen und konnte keine FOSS-Bug-Tracking-Software finden, die es 1991-1992 gab. Bugzilla, Request-Tracker und andere kamen viel später, so dass sie anscheinend draußen waren.

Schlüsselfrage

1. Wie haben damals Linus, die Subsystembetreuer und Benutzer, Fehler gemeldet und nachverfolgt?
2. Haben sie eine Bug-Tracking-Software verwendet, einen Bug-Zweig erstellt und manuell Fragen und Diskussionen zu dem darin enthaltenen Bug durchgeführt (das wäre teuer und schmerzhaft) oder einfach nur eine E-Mail verwendet?
3. Viel später erschien Bugzilla (erste Veröffentlichung 1998) und dies scheint der primäre Weg zu sein, um Fehler danach zu melden .

Ich freue mich darauf, ein klareres Bild davon zu bekommen, wie die Dinge in früheren Tagen gemacht wurden.

Wenn Sie am Anfang etwas beizutragen hatten (einen Patch oder einen Fehlerbericht), haben Sie ihn an Linus gesendet. Dies führte dazu, dass es an die Liste gesendet wurde (die linux-kernel@vger.rutgers.eduzuvor kernel.orgerstellt wurde).

Es gab keine Versionskontrolle. Von Zeit zu Zeit legte Linus einen Tarball auf den FTP-Server. Dies war das Äquivalent eines "Tags". Die am Anfang verfügbaren Tools waren RCS und CVS, und Linus hasst diese, so dass alle nur Patches verschickt haben. (Es gibt eine Erklärung von Linus, warum er CVS nicht verwenden wollte.)

Es gab andere proprietäre Versionskontrollsysteme vor Bitkeeper, aber die dezentrale, freiwillige Entwicklung von Linux machte es unmöglich, sie zu verwenden. Eine zufällige Person, die gerade einen Fehler gefunden hat, wird niemals einen Patch senden, wenn er ein proprietäres Versionskontrollsystem mit Lizenzen durchlaufen muss, die in Tausenden von Dollar beginnen.

Bitkeeper hat diese beiden Probleme umgangen: Es war nicht wie CVS zentralisiert, und obwohl es keine freie Software war, durften Kernel-Autoren es ohne Bezahlung verwenden. Das machte es für eine Weile gut genug.

Selbst bei der heutigen git-basierten Entwicklung sind die Mailinglisten immer noch da, wo es lang geht. Wenn Sie etwas beitragen möchten, bereiten Sie es natürlich mit git vor, aber Sie müssen es auf der entsprechenden Mailingliste besprechen, bevor es zusammengeführt wird. Bugzilla ist da, um "professionell" auszusehen und halbherzige Fehlerberichte von Leuten aufzusaugen, die nicht wirklich mitmachen wollen.

Um einige der alten Anweisungen zum Melden von Fehlern anzuzeigen, rufen Sie das historische Linux-Repository ab . (Dies ist ein Git-Repository, das alle Versionen vor dem Bestehen von Git enthält. Meistens enthält es ein Commit pro Release, seit es aus den Tarballs rekonstruiert wurde.) Dateien in der Nähe sind README, MAINTAINERSund REPORTING-BUGS.

Eines der interessanten Dinge, die Sie dort finden können, ist das in der README-Datei für 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.

Die Prozesse verwendeten Newsgroups (USENET) und (überwiegend) E-Mail. Ein Fehler "existierte" als Thread, " [BUG REPORT]" oder " LINUX BUG REPORT" in das Thema einzufügen, war eine übliche Konvention. Es gab keine Bug-IDs. In Anbetracht der typischen Benutzerbasis wurde ein Fehlerbericht oft mit einem Patch geliefert. Es wurde ein längst vergessenes Software-Tool verwendet: ibug(siehe unten), außer dem diff+ patch.

Von Linux-Installation und Erste Schritte (Archivierte Kopie von Januar 1994, Version 2.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

Hier ist ein Fehlerbericht und eine Fehlerbehebung von Dezember 1992 (0.98.6) auf comp.os.linux: https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion

Sehr früh gab es eine E - Mail-Liste ml-linux-bugs (1992/1993) aus dieser frühen FAQ in der Slackware 1.01-Distribution:

VI.01) $ # @! Unter Linux portiert läuft nicht richtig. Was kann ich tun, um Fehler zu melden?

[...] Beachten Sie, dass meine Fehlerberichtsliste "ml-linux-bugs@dg-rtp.dg.com" ausgelaufen ist. Es stellt sich heraus, dass Linux so wenige Fehler aufweist, von denen die meisten in der Newsgroup oder über Linus behoben werden, bevor ich sie sammeln und veröffentlichen kann. :) Kurz gesagt: Wenn es einen Fehler in Linux oder in Linux-portierter Software gibt, wird dieser normalerweise in der nächsten Patch-Version oder Version behoben.

Es gab die "Linux-Kernel" vger-E- Mail-Liste (die auf dem Original lief ), Newsgroups alt.os.linux, dann comp.os.linux (die sich 1993 schnell in eine Hierarchie aufteilte ).

In dieser frühen Linux-FAQ (1.11.1992) von comp.os.linux wird auch empfohlen, Linus direkt eine E-Mail zu senden .

1992 kündigte Matt Welsh ( Linux , Linux Bible , TLDP ) anibug , bei der Generierung von per E-Mail versendeten Fehlerberichten behilflich zu sein (ironischerweise konnte dies zu diesem Zeitpunkt nicht unter Linux ausgeführt werden, da es nicht genügend Netzwerke gab, um eine E-Mail senden zu können).

Eine E-Mail- Fehlerberichtvorlagelinux.temp wurde ebenfalls regelmäßig auf comp.os.linux veröffentlicht, und Aktualisierungen eines Fehlerberichts enthielten eine Aktualisierungsvorlagelinux.fix.temp .

Es gab auch ein Patch-Repository (FTP) , soweit ich das beurteilen kann, das hauptsächlich (nicht ausschließlich) für Patches für Programme zur Portierung auf Linux gedacht war.

1993-1994

CVS-Kopien der Kernel-Quelle waren weit verbreitet, das früheste, was ich finden kann, ist Dirk Steinbergs aus der Ära kernal-0.99.14. Die erste Ankündigung, die ich finden kann, ist ab Januar 1993 bei Linux-Aktivisten. Sie können immer noch archivierte Exemplare (1994) finden . Dirk hat auch die cvs-Binärdateien und die libc-Quelle in CVS gepflegt.

CVS wurde nicht zum Verfolgen von Fehlern im heutigen Sinne verwendet, einige Entwickler bevorzugten es und Patches wurden häufig in Form von CVS-generierten Diffs eingereicht.

1995-1996

Ungefähr zu dieser Zeit (Oktober 1995) begann David S. Miller CVS für den SPARC-Port des Linux-Kernels ( Der Linux / SPARC-Port ) zu verwenden. Bis Februar 1996 verwendeten mehrere andere Kernel-Entwickler CVS unabhängig voneinander, um Patches zu verfolgen, von Linux-Kernel diesen Thread und diesen Thread : Alan Cox, Stephen Tweedie, Kai Henningsen. (Der zweite Thread berichtet über Russ Nelson, der die Abneigung von Linus gegen CVS aus erster Hand anführt.)

1997-1998

Im April 1998, kurz nach der Geburt von Linus 'zweitem Kind, tauchte das Thema CVS erneut auf, siehe diesen Untertitel vom Linux-Kernel (Linus bekräftigt seine Besorgnis über CVS direkt dort).

Im Dezember 1997 veröffentlichte Andrew Tridgell Jitterbug , einen webbasierten Bug-Tracker. Bis Juni 1998 wurde der "Linux-Patches" JitterBug von Alan Cox auf Linux-Kernel befürwortet . Soweit ich das beurteilen kann, war dies das erste von Linus und anderen wichtigen Entwicklern verwendete Fehlerverfolgungssystem. Leider ist die Instanz "linux-patches" nicht mehr online.

Im September 1998 wird Bitkeeper von Larry McEvoy zum ersten Mal auf Linux-Kernel befördert .

1999 und später

Durch 1999/2000 die lkml FAQ gestartet Bezug (Q 1-16) auf den CVS - Baum auf (das Original) Vger. Dies wurde zu der Zeit von Andrew Tridgell gepflegt.

Bis Dezember 2001 war Jitterbug in Ungnade gefallen. Sehen Sie, wie dieser Linux-Kernel- Thread , Linus, Alan Cox und viele andere sich in die Diskussion einmischen, warum.

Im Januar 2002 begann sich Linus für Bitkeeper zu interessieren (das bereits vom PowerPC Linux-Kernel-Team verwendet wurde).

Im Februar 2002 begann Linus, Bitkeeper für den 2.5-Entwicklungsbaum zu verwenden.

Im November 2002 wurde das von OSDL gehostete Linux Bugzilla für den 2.5-Baum angekündigt . (Wenn Sie den Bugzilla-Link in der Frage noch nicht gelesen haben , lesen Sie ihn jetzt, er enthält alte Linus-Rants.)

Im April 2005 kündigte Linus eine Abkehr von BitKeeper , um die Zeit er zum ersten Mal erwähnt gitnamentlich . Kurz nachdem git in der Lage war, sich selbst zu hosten , stellte Linus die Verwendung von BitKeeper ein und begann, git für den Kernel zu verwenden.

Im Dezember 2008 wurde der Patchwork- Patch-Tracker für den Linux-Kernel angekündigt . Hierbei handelt es sich um einen SCCS-unabhängigen, webbasierten Patch-Tracker, der in Mailinglisten integriert ist, um Patches und Follow-ups zu verfolgen. Die Nutzung dauert bis heute an. Auf https://patchwork.kernel.org/ werden ungefähr 40 Listen auf diese Weise verfolgt , obwohl nicht alle aktiv sind.

Verweise

Nützliche Hinweise:

• Essenz verteilter Arbeit: Der Fall des Linux-Kernels (Jae Yun Moon, Lee Sproull) http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (Nov 2000)
• Richtlinien zum Melden von Linux-Fehlern (Jul 1992) http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
• Kenneth R. Saborios Archiv wichtiger Linux-Postings / E-Mails: http://www.informatica.co.cr/linux/index.htm (1991-2005)
• Linux-Kernel-Archive von heute (November 2014) zurück bis 1995 http://lkml.iu.edu/hypermail/linux/kernel/ (leider ist die erste E-Mail von Juni 1995, in der der Administrator Chris Dent mitteilt, dass er die frühere verloren hat Archive ...) Das LKML- Archiv stammt erst aus dem Jahr 1996
• Fragmente von Linux-devel 1993-1994 von tsx11 http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux- devel / (ignoriere die Daten in der URL und in den Dateien)
• Versionsverwaltungstools: CVS to BK im Linux Kernel , Sjaikh & Cornford (ca. 2003)
• Siehe auch diese Hacker News Thread (März 2015) zum 10-jährigen Jubiläum von git: https://news.ycombinator.com/item?id=9263336

Ich kann sagen, wie die Fehlerberichterstattung für die Entwicklung gitselbst gehandhabt wird .

Sie verwenden keine Bug-Tracking-Software. Fehler werden auf der Entwicklungs-Mailingliste gemeldet und besprochen . Es ist möglicherweise überraschend, funktioniert aber sehr gut.

Die Frage oder der Vorschlag, eine Fehlerverfolgungssoftware zu verwenden, taucht häufig auf, sodass Sie beim Durchsuchen der git-Mailinglisten-Archive viel darüber lernen können.

Es geht nicht um "Wir haben noch keinen Bug-Tracker gefunden, der gut genug ist";
Es geht aber auch nicht um "Wir haben eine überlegene Methode".

Bei dieser Methode spielt der Projektbetreuer oder Teilprojektbetreuer - so etwas wie ein leitender Entwickler - eine wichtige Rolle als informeller Moderator der Entwicklungsliste.
Der Umgang mit Fehlern ist ein Teil davon, und es scheint keine triviale Aufgabe zu sein, Fehler auf diese Weise zu verwalten. Es hängt sicherlich von den Fähigkeiten der Personen in dieser Rolle ab.

Der formalste Teil der Methode ist eine wöchentliche Statuszusammenfassung.
Es listet die Dinge, die derzeit in den verschiedenen Filialen vor sich gehen, als kurze Elemente auf. Ein Beispiel aus der Git-Entwicklung finden Sie in der Newsgroup, gmane.comp.version-control.gitdie die Mailingliste widerspiegelt : Was ist Kochen in git.git?

Was ich mit Sicherheit sagen kann: Wenn Sie einen Betreuer haben, der darin gut ist, funktioniert es sehr gut.
Zum Beispiel wäre ich sehr überrascht, wenn sich die Einführung eines Bug-Trackers positiv auf die Produktivität der implementierten Funktionen und die Qualität auswirken würde, auch langfristig nach Amortisation des Änderungsaufwands.

Für den Linux-Kernel ist es ähnlich wie für Git bis heute.
Die Entwicklungsmailinglisten für die Linux-Kernel-Entwicklung sind sicherlich wichtig. Aber es ist nicht eine Liste als zentraler Ort wie bei Git. Es gibt separate Listen für Unterthemen wie Dateisysteme oder Netzwerke.
Da es separate Themen gibt, die größtenteils von separaten Entwicklern behandelt werden, können einige Gruppen Tools lokal für ihre Gruppe verwenden.