W procesach wykorzystano grupy dyskusyjne (USENET) i (głównie) e-maile. Błąd „istniał” jako wątek, umieszczenie „ [BUG REPORT]” lub „ LINUX BUG REPORT” w temacie było powszechną konwencją. Nie było identyfikatorów błędów. Biorąc pod uwagę typową bazę użytkowników, raport o błędach często zawierał łatkę. Użyto jednego dawno zapomnianego narzędzia programowego: ibug(patrz poniżej), innego niż to diff+ patch.
Z Linuksa Instalacja i wprowadzenie (styczeń 1994, zarchiwizowana kopia 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
Oto raport o błędzie i poprawka z grudnia 1992 r. (0.98.6) na comp.os.linux:
https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion
Bardzo wcześnie pojawiła się lista e - mail ml-linux-bugs (1992/1993), z tego wczesnego FAQ w dystrybucji Slackware 1.01:
VI.01) Wygląda na to, że $ # @! portowane na Linuksie nie działają poprawnie, co zrobić z zgłaszaniem błędów?
[...] Zauważ, że moja lista zgłoszeń błędów „ml-linux-bugs@dg-rtp.dg.com” została wycofana. Okazuje się, że Linux ma tak mało błędów, z których większość jest rozwiązywana na grupie dyskusyjnej lub przez Linusa, zanim będę mógł je zebrać i opublikować. :) W skrócie: jeśli w systemie Linux lub w oprogramowaniu do niego instalowanym występuje błąd, zwykle zostanie on naprawiony w następnym poziomie lub wersji łatki.
Istniała lista adresów e-mail „jądra linuxa” (która działała na oryginale vger), grupy dyskusyjne alt.os.linux, a następnie comp.os.linux (która szybko rozpadła się na hierarchię w 1993 r .).
Ten wczesny Linux FAQ (v1.11 listopada 1992) z comp.os.linux sugeruje również wysyłając Linus bezpośrednio.
W 1992 Matt Welsh ( działający Linux , Linux Bible , TLDP ) ogłosił, żeibug będzie pomagał w generowaniu raportów o błędach wysyłanych pocztą elektroniczną (jak na ironię, nie można było uruchomić tego w systemie Linux w tym czasie, ponieważ brakowało wystarczającej sieci, aby móc wysłać wiadomość e-mail).
Szablon raportu o błędachlinux.temp e-mail był także okresowo publikowany na stronie comp.os.linux, a aktualizacje raportu o błędach zawierały szablon aktualizacjilinux.fix.temp .
Istniało również repozytorium łatek (FTP) , o ile mogę stwierdzić, że było to głównie (nie wyłącznie) łaty do programów do portowania na Linuksie.
1993–1994
Kopie CVS źródła jądra były powszechne, najwcześniej mogę znaleźć Dirka Steinberga z ery jądra 0.99.14. Pierwsza zapowiedź znajdę to od stycznia 1993 na Linux-aktywistów. Nadal można znaleźć zarchiwizowane kopie (1994) . Dirk utrzymywał również pliki binarne cvs i źródło libc w CVS.
CVS nie był używany do śledzenia błędów we współczesnym znaczeniu, niektórzy programiści woleli go używać, a łatki były często przesyłane w postaci różnic generowanych przez CVS.
1995–1996
Mniej więcej w tym czasie (październik 1995) David S. Miller zaczął używać CVS jako portu SPARC jądra Linux ( port Linux / SPARC ). Do lutego 1996 r. Kilku innych programistów jądra samodzielnie używało CVS do śledzenia łatek, od jądra linuxa ten wątek i ten wątek : Alan Cox, Stephen Tweedie, Kai Henningsen. (Drugi wątek informuje Russa Nelsona o niechęci Linusa z pierwszej ręki do CVS.)
1997–1998
W kwietniu 1998 r., Krótko po urodzeniu drugiego dziecka Linusa, ponownie pojawiła się kwestia CVS, z jądra Linuksa zobacz ten podtytuł (Linus bezpośrednio wyraża swoje obawy dotyczące CVS).
W grudniu 1997 roku Andrew Tridgell wydał jitterbug , internetowy moduł śledzenia błędów. W czerwcu 1998 r. Alan Cox promował „łaty linuksowe” JitterBuga na jądrze Linuksa . Było to, o ile wiem, pierwszy rzeczywisty system śledzenia błędów używany przez Linusa i innych kluczowych programistów, niestety instancja „łatek linuksowych” nie jest już dostępna online.
We wrześniu 1998 r. Program Bitkeeper został po raz pierwszy wypromowany w jądrze systemu Linux przez Larry'ego McEvoya.
1999 i później
Do 1999/2000 FAQ lkml zaczęło odwoływać się (Q 1-16) do drzewa CVS na (oryginalnym) vgerze. W tym czasie utrzymywał to Andrew Tridgell.
W grudniu 2001 roku Jitterbug stracił przychylność, zobacz ten wątek jądra Linuksa , Linus, Alan Cox i wielu innych, angażujących się w dyskusję o tym, dlaczego.
Do stycznia 2002 Linus zaczął interesować się bitkeeperem (używanym już przez zespół jądra PowerPC Linux).
W lutym 2002 Linus zaczął używać Bitkeeper do drzewa programistycznego 2.5.
W listopadzie 2002 roku odbyło OSDL Linux Bugzilli na drzewo 2.5 zostało ogłoszone . (Jeśli jeszcze nie przeczytałeś linku do bugzilli w pytaniu, idź i przeczytaj go teraz, zawiera on vintage rants Linusa).
W kwietniu 2005 r. Linus ogłosił odejście od BitKeepera , mniej więcej w tym czasie, kiedy po raz pierwszy wspomniał gitz nazwiska . Krótko po tym, jak git stał się zdolny do samodzielnego hostingu , Linus przestał używać BitKeepera i zaczął używać git do jądra.
W grudniu 2008 roku ogłoszono patchwork patch tracker dla jądra Linuksa. Jest to niezależny od SCCS internetowy tracker łatek, który integruje się z listami mailowymi w celu śledzenia łatek i działań następczych. Jego użycie trwa do dziś, istnieje około 40 list śledzonych w ten sposób na https://patchwork.kernel.org/ , chociaż nie wszystkie są aktywne.
Referencje
Przydatne referencje: