W jaki sposób projekt jądra Linux śledził błędy we wczesnych dniach?

Wszyscy wiemy, że Linus Torvalds stworzył Git z powodu problemów z Bitkeeper. Nie wiadomo (przynajmniej dla mnie), w jaki sposób śledzono problemy / bilety / błędy? Próbowałem, ale nie dostałem nic ciekawego. Jedyną dyskusją, jaką mogłem podjąć na ten temat, była ta, w której Linus podzielił się obawami związanymi z używaniem Bugzilli .

Spekulacje: - Najłatwiejszym sposobem na śledzenie błędów w początkowej fazie byłoby umieszczenie zgłoszeń we własnej gałęzi, ale jestem pewien, że dość szybko nie dałoby się to zrobić, gdy hałas przejąłby dobre błędy.

Widziałem Bugzillę i korzystałem z niej, a jeśli nie znasz odpowiednich „słów kluczowych”, czasami byłbyś zaskoczony. UWAGA: jestem specjalnie zainteresowany we wczesnych latach (1991-1995), jak one wykorzystywane do śledzenia problemów.

Patrzyłem na dwa wątki: „ Saga jądra SCM ” i „ Ciekawostki: kiedy Git sam się hostował? ”, Ale żaden z nich nie wspomniał o śledzeniu błędów jądra we wczesnych dniach.

Szukałem i nie byłem w stanie znaleźć żadnego oprogramowania do śledzenia błędów FOSS, które istniało w latach 1991-1992. Bugzilla, Request-tracker i inne pojawiły się znacznie później, więc wydają się być niedostępne.

Kluczowe pytania

1. W jaki sposób Linus, opiekunowie podsystemów i użytkownicy zgłaszali i śledzili błędy w tych dniach?
2. Czy użyli oprogramowania do śledzenia błędów, stworzyli gałąź błędów i ręcznie zadawali pytania i dyskusje na temat błędu (byłoby to drogie i bolesne), czy po prostu używali poczty e-mail.
3. Znacznie później pojawiła się Bugzilla (pierwsze wydanie 1998) i wydaje się, że jest to główny sposób zgłaszania błędów później .

Nie możemy się doczekać, aby uzyskać wyraźniejszy obraz tego, jak rzeczy były robione w starszych czasach.

Na początku, jeśli miałeś coś do dodania (łatkę lub raport o błędzie), wysłałeś to do Linusa. Przekształciło się to w [email protected]wysłanie go na listę (która wcześniej kernel.orgbyła tworzona).

Nie było kontroli wersji. Od czasu do czasu Linus umieszczał archiwum na serwerze FTP. To był odpowiednik „tagu”. Na początku dostępne były narzędzia RCS i CVS, a Linus ich nienawidzi, więc wszyscy wysyłali łatki. ( Linus wyjaśnia, dlaczego nie chciał używać CVS).

Były inne zastrzeżone systemy kontroli wersji sprzed Bitkeepera, ale zdecentralizowany, oparty na wolontariacie rozwój Linuksa uniemożliwił korzystanie z nich. Przypadkowa osoba, która właśnie znalazła błąd, nigdy nie wyśle ​​łaty, jeśli będzie musiała przejść przez zastrzeżony system kontroli wersji z licencjami zaczynającymi się od tysięcy dolarów.

Bitkeeper poradził sobie z obydwoma tymi problemami: nie był scentralizowany jak CVS i chociaż nie było to Wolne Oprogramowanie, współautorzy jądra mogli go używać bez płacenia. Przez chwilę było wystarczająco dobrze.

Nawet przy dzisiejszym rozwoju opartym na git, listy mailingowe wciąż są tam, gdzie jest akcja. Jeśli chcesz coś wnieść, przygotujesz to oczywiście git, ale musisz omówić to na odpowiedniej liście mailingowej, zanim zostanie scalona. Bugzilla ma na celu wyglądać „profesjonalnie” i chłonąć na wpół upieczone raporty o błędach od ludzi, którzy tak naprawdę nie chcą się zaangażować.

Aby zobaczyć niektóre stare instrukcje zgłaszania błędów, pobierz historyczne repozytorium Linux . (Jest to repozytorium git zawierające wszystkie wersje sprzed git; przeważnie zawiera jedno zatwierdzenie na wydanie, ponieważ zostało zrekonstruowane z archiwów tar). Pliki to także README, MAINTAINERSi REPORTING-BUGS.

Jedną z interesujących rzeczy, które można tam znaleźć, jest README dla Linux-0.99.12:

 - 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.

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 „[email protected]” 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:

• Istota rozproszonej pracy: przypadek jądra Linuxa (Jae Yun Moon, Lee Sproull) http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (listopad 2000)
• Wskazówki dotyczące zgłaszania błędów w systemie Linux (lipiec 1992 r.) Http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
• Archiwum Kennetha R. Saborio ważnych postów / e-maili dotyczących Linuksa: http://www.informatica.co.cr/linux/index.htm (1991-2005)
• archiwum jądra linux-a od dzisiaj (listopad 2014) do 1995 http://lkml.iu.edu/hypermail/linux/kernel/ (niestety, pierwszy e-mail pochodzi z czerwca 1995 r., gdzie administrator Chris Dent ogłasza, że ​​stracił wcześniej archiwa ...) Archiwum LKML sięga 1996 roku
• Fragmenty z linux-devel 1993-1994 z tsx11 http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux- devel / (ignoruj ​​daty w adresie URL i plikach)
• Narzędzia do zarządzania wersjami : CVS do BK w jądrze Linux , Sjaikh i Cornford (ok. 2003)
• Zobacz także ten wątek Hacker News (marzec 2015 r.), Gdy zbliża się 10. rocznica git: https://news.ycombinator.com/item?id=9263336

Potrafię powiedzieć, jak obsługiwane jest zgłaszanie błędów w celu rozwoju gitsamego siebie.

Nie używają żadnego oprogramowania do śledzenia błędów. Błędy są zgłaszane i omawiane na liście mailingowej dla programistów . To może być zaskakujące, ale działa bardzo dobrze.

Często pojawia się pytanie lub propozycja korzystania z oprogramowania do śledzenia błędów, więc możesz dowiedzieć się o tym dużo, przeszukując archiwa list mailowych git.

Nie chodzi o to, że „nie znaleźliśmy jeszcze wystarczająco dobrego narzędzia do śledzenia błędów”;
Ale nie chodzi również o „mamy lepszą metodę”.

Dzięki tej metodzie opiekun projektu lub podprojektu - coś w rodzaju wiodącego programisty - odgrywa ważną rolę jako nieformalny moderator listy programistów.
Obsługa błędów jest jego częścią i wydaje się, że zarządzanie błędami w ten sposób nie jest trywialne; Z pewnością zależy to od umiejętności osób pełniących tę rolę.

Najbardziej formalną częścią metody jest cotygodniowe podsumowanie statusu.
Wymienia rzeczy, które aktualnie dzieją się w różnych gałęziach, jako krótkie artykuły. Na przykład z rozwoju git, zobacz to w grupie dyskusyjnej gmane.comp.version-control.gitdublowanie listy mailingowej: Co gotuje w git.git

Co mogę powiedzieć na pewno: jeśli masz opiekuna, który jest w tym dobry, działa to wyjątkowo dobrze.
Na przykład byłbym bardzo zaskoczony, gdyby wprowadzenie narzędzia do śledzenia błędów miało pozytywny wpływ na produktywność zaimplementowanych funkcji i jakości, nawet w długim okresie po amortyzacji kosztów zmian.

W przypadku jądra Linuksa wygląda to podobnie jak w przypadku git aż do dzisiaj.
Listy mailingowe dla programistów jądra Linux są z pewnością ważne. Ale nie jest to jedna lista jako centralne miejsce jak w przypadku git. Istnieją osobne listy dla podtematów, takich jak systemy plików lub sieci.
Ponieważ istnieją osobne tematy, obsługiwane głównie przez oddzielnych programistów, możliwe jest, że niektóre grupy używają narzędzi lokalnie do swojej grupy.