Wenn Sie am Anfang etwas beizutragen hatten (einen Patch oder einen Fehlerbericht), schickten Sie es an Linus. Dies entwickelte sich zum Versenden an die Liste (das war [email protected] vor kernel.org wurde erstellt).
Es gab keine Versionskontrolle. Von Zeit zu Zeit legte Linus einen Tarball auf dem FTP-Server ab. Dies war das Äquivalent eines "Tags". Die verfügbaren Tools am Anfang waren RCS und CVS, und Linus hasst diese, also schickte jeder einfach Patches. (Es gibt eine Erklärung von Linus, warum er CVS nicht verwenden wollte.)
Es gab andere proprietäre Versionskontrollsysteme vor Bitkeeper, aber die dezentrale, auf Freiwilligen basierende 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 zentralisiert wie CVS, und obwohl es keine Freie Software war, durften Kernel-Beitragende es nutzen, ohne dafür zu bezahlen. Damit war es für eine Weile gut genug.
Selbst bei der heutigen Git-basierten Entwicklung sind die Mailinglisten immer noch der Ort, an dem die Action stattfindet. Wenn Sie etwas beitragen möchten, bereiten Sie es natürlich mit Git vor, aber Sie müssen es auf der entsprechenden Mailingliste diskutieren, bevor es zusammengeführt wird. Bugzilla ist da, um „professionell“ auszusehen und halbgare Fehlerberichte von Leuten aufzusaugen, die es wirklich nicht tun mitmachen möchten.
Um einige der alten Anweisungen zum Melden von Fehlern zu sehen, holen Sie sich das historische Linux-Repository. (Dies ist ein Git-Repository, das alle Versionen enthält, bevor Git existierte; meistens enthält es einen Commit pro Release, da es aus den Tarballs rekonstruiert wurde). Zu den interessanten Dateien gehört README , MAINTAINERS , und REPORTING-BUGS .
Eines der interessanten Dinge, die Sie dort finden können, ist dies in der Linux-0.99.12 README:
- 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.
Die Prozesse verwendeten Newsgroups (USENET) und (überwiegend) E-Mail. Ein Fehler „existierte“ als Thread, der „[BUG REPORT] " oder "LINUX BUG REPORT " im Betreff war eine gängige Konvention. Es gab keine Fehler-IDs. Angesichts der typischen Benutzerbasis kam ein Fehlerbericht oft mit einem Patch. Es wurde ein lange vergessenes Software-Tool verwendet:ibug (siehe unten), außer diesem diff +patch .
Aus Linux-Installation und Erste Schritte (Januar 1994, v2.0 archivierte Kopie)>
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 vom 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) Es scheint, dass $#@! ported on linux laufen nicht korrekt, was kann ich tun, um Fehler zu melden?
[...]Beachten Sie, dass meine Fehlermeldeliste "[email protected]" ausgelaufen ist. Es stellt sich heraus, dass Linux so wenige Bugs hat, von denen die meisten in der Newsgroup oder durch Linus behoben werden, bevor ich sie sammeln und posten kann. :) Kurz gesagt:Wenn es einen Fehler in Linux oder in Linux-portierter Software gibt, wird er normalerweise im nächsten Patchlevel oder in der nächsten Version behoben.
Es gab die "linux-kernel"-E-Mail-Liste (die auf dem ursprünglichen vger lief ), Newsgroups alt.os.linux, dann comp.os.linux (die sich 1993 schnell in eine Hierarchie aufspalteten).
Diese frühe Linux-FAQ (v1.11 Nov 1992) von comp.os.linux schlägt auch vor, Linus direkt eine E-Mail zu schicken.
1992 Matt Welsh (Running Linux , Linux-Bibel , TLDP) hat ibug angekündigt um bei der Generierung von Fehlerberichten per E-Mail zu helfen (ironischerweise konnten Sie dies zu dieser Zeit nicht unter Linux ausführen, da es nicht genügend Netzwerk gab, um eine E-Mail senden zu können).
Eine E-Mail-Fehlerberichtsvorlage linux.temp wurde auch regelmäßig auf comp.os.linux gepostet, und Aktualisierungen eines Fehlerberichts hatten eine Aktualisierungsvorlage linux.fix.temp .
Es gab auch ein Patch-Repository (FTP), soweit ich das beurteilen kann, war dies hauptsächlich (nicht ausschließlich) für Patches für Programme zur Portierung auf Linux.
1993-1994
CVS-Kopien der Kernel-Quellen waren weit verbreitet, die früheste, die ich finden kann, ist die von Dirk Steinberg aus der Kernal-0.99.14-Ära. Die erste Ankündigung, die ich finden kann, ist vom Januar 1993 auf linux-activists. Sie können noch archivierte Kopien (1994) finden. Dirk pflegte auch CVS-Binärdateien und den Libc-Quellcode in CVS.
CVS wurde nicht zum Verfolgen von Fehlern im heutigen Sinne verwendet, einige Entwickler zogen es vor, es zu verwenden, 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 die SPARC-Portierung des Linux-Kernels zu verwenden (Die Linux/SPARC-Portierung ).Im Februar 1996 benutzten mehrere andere Kernel-Entwickler unabhängig voneinander CVS, um Patches zu verfolgen, von linux-kernel this thread und this thread:Alan Cox, Stephen Tweedie, Kai Henningsen. (Der zweite Thread berichtet von Russ Nelson, der Linus' Abneigung gegen CVS aus erster Hand äußert.)
1997-1998
Im April 1998, kurz nach der Geburt von Linus' zweitem Kind, tauchte das Thema CVS erneut auf, vom Linux-Kernel siehe diesen Unterthread (Linus wiederholt dort direkt seine Bedenken bezüglich CVS).
Im Dezember 1997 veröffentlichte Andrew Tridgell Jitterbug, einen webbasierten Bugtracker. Bis Juni 1998 wurden die "Linux-Patches" JitterBug von Alan Cox auf dem Linux-Kernel befürwortet. Dies war, soweit ich das beurteilen kann, das erste eigentliche Bug-Tracking-System, das von Linus und anderen wichtigen Entwicklern verwendet wurde, leider ist die "linux-patches"-Instanz nicht mehr online.
Im September 1998 wird Bitkeeper erstmals von Larry McEvoy auf dem Linux-Kernel beworben.
1999 und später
1999/2000 begann die lkml-FAQ (Fragen 1-16) auf den CVS-Baum auf (dem Original) vger zu verweisen. Dies wurde damals von Andrew Tridgell gepflegt.
Bis Dezember 2001 war Jitterbug in Ungnade gefallen, siehe diesen Linux-Kernel-Thread, Linus, Alan Cox und viele andere beteiligen sich an der Diskussion darüber, warum.
Im Januar 2002 fing Linus an, sich für Bitkeeper zu interessieren (bereits vom PowerPC-Linux-Kernel-Team verwendet).
Im Februar 2002 begann Linus, Bitkeeper für den 2.5-Entwicklungsbaum zu verwenden.
Im November 2002 wurde der 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 seinen Wechsel von BitKeeper an, ungefähr zu der Zeit, als er git zum ersten Mal erwähnte namentlich. Kurz nachdem Git in der Lage war, sich selbst zu hosten, hörte Linus auf, BitKeeper zu verwenden, und fing an, Git für den Kernel zu verwenden.
Im Dezember 2008 wurde der Patchwork-Patch-Tracker für Linux-Kernel angekündigt, dies ist ein SCCS-agnostischer webbasierter Patch-Tracker, der sich in Mailinglisten integriert, um Patches und Folgemaßnahmen zu verfolgen. Seine Verwendung dauert bis heute an, es gibt ungefähr 40 Listen, die auf https://patchwork.kernel.org/ auf diese Weise verfolgt werden, obwohl nicht alle aktiv sind.
Referenzen
Nützliche Referenzen:
- Wesen 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 (Juli 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 stammt die erste E-Mail vom Juni 1995, in der der Administrator Chris Dent bekannt gibt, dass er verloren hat die früheren Archive ...) Das LKML-Archiv reicht nur bis 1996 zurück
- Fragmente von linux-devel 1993-1994 von tsx11http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/ linux-devel/(Ignorieren Sie die Datumsangaben in der URL und auf den Dateien)
- Versionsverwaltungstools:CVS zu BK im Linux-Kernel , Sjaikh &Cornford (ca. 2003)
- Siehe auch diese Hacker News Thread (März 2015), da der 10. Jahrestag von Git näher rückt:https://news.ycombinator.com/item?id=9263336
Ich kann sagen, wie Fehlerberichte für die Entwicklung von git gehandhabt werden selbst.
Sie verwenden keine Bug-Tracking-Software. Fehler werden auf der Entwicklungs-Mailingliste gemeldet und diskutiert. Es ist möglicherweise überraschend, funktioniert aber sehr gut.
Die Frage oder der Vorschlag, eine Fehlerverfolgungssoftware zu verwenden, wird häufig gestellt, sodass Sie beim Durchsuchen der Git-Mailinglistenarchive viel darüber erfahren können.
Es geht nicht um „wir haben noch keinen Bugtracker gefunden, der gut genug ist“;
Aber es geht auch nicht um "wir haben eine überlegene Methode".
Bei dieser Methode spielt der Betreuer des Projekts oder Teilprojekts – so etwas wie ein leitender Entwickler – eine wichtige Rolle als informeller Moderator der Entwicklungsliste.
Der Umgang mit Fehlern gehört dazu, 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 Statuszusammenfassungsnachricht.
Es listet die aktuellen Vorgänge in den verschiedenen Zweigen als kurze Einträge auf. Ein Beispiel aus der Git-Entwicklung finden Sie in der Newsgroup gmane.comp.version-control.git Spiegeln der Mailingliste:Was in git.git kocht
Was ich mit Sicherheit sagen kann:Wenn Sie einen Betreuer haben, der das gut kann, funktioniert es sehr gut.
Ich wäre zum Beispiel sehr überrascht, ob sich die Einführung eines Bugtrackers auch langfristig nach Amortisation des Änderungsaufwands positiv auf Produktivität, implementierte Features und Qualität ausgewirkt hat.
Für den Linux-Kernel ist es bis heute ähnlich wie für Git.
Die Entwicklungs-Mailinglisten 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 meist von separaten Entwicklern behandelt werden, ist es möglich, dass einige Gruppen Tools lokal für ihre Gruppe verwenden.