In che modo il progetto Linux Kernel ha tracciato i bug nei primi giorni?

Sappiamo tutti che Linus Torvalds ha creato Git a causa di problemi con Bitkeeper. Ciò che non è noto (almeno per me) è, come sono stati rilevati i problemi / i biglietti / i bug fino ad allora? Ho provato ma non ho ottenuto nulla di interessante. L'unica discussione che ho potuto approfondire è stata quella in cui Linus ha condiviso le preoccupazioni sull'uso di Bugzilla .

Speculazione: - Il modo più semplice per le persone di tracciare i bug nella fase iniziale sarebbe stato quello di mettere i biglietti in un ramo a sé stante, ma sono sicuro che abbastanza rapidamente che non si sarebbe ridimensionato con il rumore che ha superato i buoni bug.

Ho visto e usato Bugzilla e, a meno che tu non conosca le giuste "parole chiave", a volte rimarrai sconcertato. NOTA: sono particolarmente interessato ai primi anni (1991-1995) su come hanno usato per tenere traccia dei problemi.

Ho esaminato due thread, " Kernel SCM saga " e " Trivia: When git self-host? ", Ma nessuno di questi ha menzionato il bug tracking del kernel nei primi giorni.

Ho cercato in giro e non sono stato in grado di ottenere alcun software di tracciamento dei bug FOSS presente nel 1991-1992. Bugzilla, Request-tracker e altri sono arrivati ​​molto più tardi, quindi sembrano essere usciti.

Domande chiave

1. In che modo Linus, i manutentori del sottosistema e gli utenti hanno segnalato e rintracciato i bug in quei giorni?
2. Hanno usato alcuni software di tracciamento dei bug, hanno creato una branca di bug e hanno posto manualmente domande e discussioni sul bug (sarebbe costoso e doloroso farlo) o semplicemente usano la posta elettronica.
3. Molto più tardi, arrivò Bugzilla (prima versione 1998) e quello sembra essere il modo principale per segnalare i bug in seguito .

Non vedo l'ora di avere un quadro più chiaro di come sono state fatte le cose nei vecchi tempi.

All'inizio, se avevi qualcosa da contribuire (una patch o una segnalazione di bug), l'hai inviata a Linus. Questo si è evoluto in una mailing alla lista (che linux-kernel@vger.rutgers.eduprima kernel.orgera stata creata).

Non c'era controllo della versione. Di tanto in tanto, Linus inseriva un tarball sul server FTP. Questo era l'equivalente di un "tag". Gli strumenti disponibili all'inizio erano RCS e CVS, e Linus odia quelli, quindi tutti hanno appena inviato patch. (C'è una spiegazione di Linus sul perché non voleva usare CVS.)

Esistevano altri sistemi di controllo della versione proprietari di Bitkeeper, ma lo sviluppo decentralizzato e basato su volontari di Linux ha reso impossibile utilizzarli. Una persona a caso che ha appena trovato un bug non invierà mai una patch se deve passare attraverso un sistema di controllo della versione proprietario con licenze a partire da migliaia di dollari.

Bitkeeper ha risolto entrambi questi problemi: non era centralizzato come CVS e sebbene non fosse un software libero, i partecipanti al kernel potevano usarlo senza pagare. Questo lo ha reso abbastanza buono per un po '.

Anche con lo sviluppo di oggi basato su git, le mailing list sono ancora dove si trova l'azione. Quando vuoi contribuire con qualcosa, lo preparerai con git ovviamente, ma dovrai discuterne sulla relativa mailing list prima che venga unito. Bugzilla è lì per sembrare "professionale" e assorbire segnalazioni di bug cotte da persone che non vogliono davvero essere coinvolte.

Per vedere alcune delle vecchie istruzioni per la segnalazione di bug, ottenere il repository Linux storico . (Questo è un repository git che contiene tutte le versioni precedenti all'esistenza di git; per lo più contiene un commit per release poiché è stato ricostruito dai tarball). I file di interesse README, MAINTAINERSe REPORTING-BUGS.

Una delle cose interessanti che puoi trovare è questa dal README 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.

I processi utilizzavano gruppi di notizie (USENET) e (principalmente) e-mail. Un bug "esisteva" come thread, inserendo " [BUG REPORT]" o " LINUX BUG REPORT" nell'argomento era una convenzione comune. Non c'erano ID bug. Data la base di utenti tipica, una segnalazione di bug è spesso accompagnata da una patch. È stato utilizzato uno strumento software dimenticato da tempo: ibug(vedi sotto), diverso da quello diff+ patch.

Da Linux Installazione e guida introduttiva (gennaio 1994, copia archiviata 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

Ecco una segnalazione di bug e una correzione da dicembre 1992 (0.98.6) su comp.os.linux: https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion

Molto presto c'era una mailing list ml-linux-bugs (1992/1993), da questa prima FAQ nella distribuzione di Slackware 1.01:

VI.01) Sembra che $ # @! portato su Linux non funziona correttamente, cosa devo fare per segnalare bug?

[...] Nota che la mia lista di segnalazione bug "ml-linux-bugs@dg-rtp.dg.com" è stata gradualmente eliminata. Si scopre che Linux ha così pochi bug, molti dei quali vengono risolti sul newsgroup o tramite Linus prima che io possa accumularli e postarli. :) In breve: se c'è un bug in Linux o in un software con porting Linux, di solito verrà corretto nel prossimo livello di patch o versione.

C'era la mailing list "linux-kernel" (che funzionava sull'originale vger), i newsgroup alt.os.linux, quindi comp.os.linux (che si divise rapidamente in una gerarchia nel 1993 ).

Le prime FAQ su Linux (v1.11 nov 1992) di comp.os.linux suggeriscono anche di inviare direttamente un'e-mail a Linus.

Nel 1992 Matt Welsh ( Running Linux , Linux Bible , TLDP ) annunciòibug di aiutare a generare segnalazioni di bug via e-mail (ironicamente, non potevi eseguirlo su Linux in quel momento poiché mancava una rete sufficiente per poter inviare un'e-mail).

Un modello di segnalazione buglinux.temp e-mail veniva periodicamente pubblicato anche su comp.os.linux e gli aggiornamenti a una segnalazione bug avevano un modello di aggiornamentolinux.fix.temp .

C'era anche un repository di patch (FTP) , per quanto posso dire che questo era principalmente (non esclusivamente) per patch a programmi per il porting su Linux.

1993-1994

Le copie CVS del sorgente del kernel erano comuni, la prima che posso trovare è quella di Dirk Steinberg, dell'era kernal-0.99.14. Il primo annuncio che posso trovare è del gennaio 1993 su attivisti di Linux. Puoi ancora trovare copie archiviate (1994) . Dirk ha anche mantenuto i file binari cvs e la fonte libc in CVS.

CVS non è stato utilizzato per tracciare i bug in senso contemporaneo, alcuni sviluppatori hanno preferito usarlo e le patch sono state spesso presentate sotto forma di diff generati da cvs.

1995-1996

In questo periodo (ottobre 1995) David S. Miller iniziò a usare CVS per la porta SPARC del kernel Linux ( la porta Linux / SPARC ). Nel febbraio 1996 molti altri sviluppatori del kernel usavano indipendentemente CVS per tenere traccia delle patch, dal kernel Linux questo thread e questo thread : Alan Cox, Stephen Tweedie, Kai Henningsen. (Il secondo thread riporta Russ Nelson che afferma l'avversione diretta di Linus nei confronti del CVS.)

1997-1998

Nell'aprile 1998, poco dopo la nascita del secondo figlio di Linus è emersa di nuovo la questione del CVS, dal kernel Linux vedere questo sottotread (Linus reitera direttamente le sue preoccupazioni sul CVS).

Nel dicembre 1997, Andrew Tridgell ha rilasciato jitterbug , un bug tracker basato sul web. A giugno 1998 il "JitterBug" di patch per Linux era sostenuto da Alan Cox sul kernel di Linux . Per quanto ne so, il primo vero sistema di tracciamento dei bug utilizzato da Linus e altri sviluppatori chiave, purtroppo l'istanza "patch di linux" non è più online.

Nel settembre 1998, Bitkeeper è stato inizialmente promosso su kernel Linux da Larry McEvoy.

1999 e successive

Entro il 1999/2000 le FAQ di lkml hanno iniziato a fare riferimento (Q 1-16) all'albero CVS su (l'originale) vger. Ciò è stato mantenuto all'epoca da Andrew Tridgell.

Nel dicembre 2001, Jitterbug era caduto in disgrazia, vedi questo thread del kernel Linux , Linus, Alan Cox e molti altri coinvolti nella discussione del perché.

Nel gennaio 2002, Linus iniziò ad interessarsi a bitkeeper (già utilizzato dal team del kernel di PowerPC Linux).

Nel febbraio 2002 Linus ha iniziato a utilizzare Bitkeeper per l'albero di sviluppo 2.5.

Nel novembre 2002 l'OSDL ha ospitato Linux Bugzilla per l'albero 2.5 è stato annunciato . (Se non hai già letto il link bugzilla nella domanda, vai a leggerlo ora, contiene rant Linus vintage).

Nell'aprile 2005 Linus annunciò un allontanamento da BitKeeper , all'incirca quando menzionò gitper la prima volta per nome . Poco dopo che git era diventato capace di auto-hosting , Linus ha smesso di usare BitKeeper e ha iniziato a usare git per il kernel.

Nel dicembre 2008 è stato annunciato il patch tracker Patchwork per Linux-kernel , questo è un tracker di patch basato sul web indipendente da SCCS che si integra con le mailing list per tracciare patch e follow-up. Il suo utilizzo continua fino ad oggi, ci sono circa 40 elenchi tracciati in questo modo su https://patchwork.kernel.org/ , sebbene non tutti siano attivi.

Riferimenti

Riferimenti utili:

• Essenza di lavoro distribuito: il caso del kernel Linux (Jae Yun Moon, Lee Sproull) http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (Nov 2000)
• Linee guida per la segnalazione di bug di Linux (luglio 1992) http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
• Archivio Kenneth R. Saborio di importanti post / e-mail su Linux: http://www.informatica.co.cr/linux/index.htm (1991-2005)
• archivi linux-kernel da oggi (novembre 2014) al 1995 http://lkml.iu.edu/hypermail/linux/kernel/ (purtroppo, la prima e-mail è del giugno 1995 in cui l'amministratore Chris Dent annuncia di aver perso il precedente archivi ...) L' archivio LKML risale al 1996
• Frammenti da Linux-Devel 1993-1994 da Tsx11 http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux- devel / (ignora le date nell'URL e nei file)
• Strumenti di gestione delle versioni: da CVS a BK nel kernel Linux , Sjaikh e Cornford (ca. 2003)
• Vedi anche questo thread di Hacker News (marzo 2015) mentre si avvicina il decimo anniversario di git: https://news.ycombinator.com/item?id=9263336

Posso dire come viene gestita la segnalazione di bug per lo sviluppo di gitse stessa.

Non usano alcun software di tracciamento dei bug. I bug vengono segnalati e discussi nella mailing list di sviluppo . È forse sorprendente, ma funziona molto bene.

La domanda o la proposta di utilizzare alcuni software di tracciamento dei bug si presenta spesso, quindi puoi imparare molto su questo dalla ricerca negli archivi delle mailing list git.

Non si tratta di "non abbiamo ancora trovato un bug tracker abbastanza buono";
Ma non si tratta nemmeno di "abbiamo un metodo superiore".

Con questo metodo, il manutentore del progetto o del sottoprogetto - qualcosa come uno sviluppatore principale - ha un ruolo importante come moderatore informale dell'elenco di sviluppo.
Gestire i bug fa parte di esso e non sembra essere un compito banale gestire i bug in questo modo; Dipende sicuramente dalle capacità delle persone in quel ruolo.

La parte più formale del metodo è un messaggio di riepilogo dello stato settimanale.
Elenca le cose attualmente in corso sui vari rami come voci brevi. Per un esempio dallo sviluppo di git, vedere questo nel newsgroup che gmane.comp.version-control.gitrispecchia la mailing list: Cosa sta cucinando in git.git

Cosa posso dire con certezza: se hai un manutentore che è bravo in questo, funziona molto bene.
Ad esempio, sarei molto sorpreso se l'introduzione di un bug tracker avesse un effetto positivo sulla produttività delle funzionalità e della qualità implementate, anche a lungo termine dopo l'ammortamento delle spese generali del cambiamento.

Per il kernel Linux, è simile a come è stato fatto per git, fino ad oggi.
Le mailing list di sviluppo per lo sviluppo del kernel Linux sono certamente importanti. Ma non è un elenco come un posto centrale come con git. Esistono elenchi separati per argomenti secondari, come filesystem o reti.
Poiché esistono argomenti separati, gestiti principalmente da sviluppatori separati, è possibile che alcuni gruppi utilizzino gli strumenti localmente per il proprio gruppo.