All'inizio, se avevi qualcosa da contribuire (una patch o una segnalazione di bug), lo inviavi a Linus. Questo si è evoluto nell'invio alla lista (che era [email protected] prima del kernel.org è stato creato).
Non c'era il controllo della versione. Di tanto in tanto, Linus metteva un tarball sul server FTP. Questo era l'equivalente di un "tag". Gli strumenti disponibili all'inizio erano RCS e CVS, e Linus li odia, quindi tutti si limitavano a spedire patch. (C'è una spiegazione da parte di Linus sul motivo per cui non voleva usare CVS.)
Esistevano altri sistemi di controllo della versione proprietari pre-Bitkeeper, ma lo sviluppo decentralizzato e basato su volontari di Linux ne ha reso impossibile l'utilizzo. 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 aggirato entrambi questi problemi:non era centralizzato come CVS e, sebbene non fosse software libero, i contributori del kernel potevano usarlo senza pagare. Questo lo ha reso abbastanza buono per un po'.
Anche con lo sviluppo odierno basato su git, le mailing list sono ancora dove si trova l'azione. Quando vuoi contribuire con qualcosa, ovviamente lo preparerai con git, ma dovrai discuterne nella mailing list pertinente prima che venga unito. Bugzilla è lì per sembrare "professionale" e assorbire segnalazioni di bug a metà da persone che non davvero vuoi essere coinvolto.
Per vedere alcune delle vecchie istruzioni di segnalazione dei bug, procurati il repository storico di Linux. (Questo è un repository git contenente tutte le versioni precedenti all'esistenza di git; per lo più contiene un commit per rilascio poiché è stato ricostruito dai tarball). I file di interesse includono README , MAINTAINERS e REPORTING-BUGS .
Una delle cose interessanti che puoi trovare è questa dal README di 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.
I processi utilizzavano newsgroup (USENET) e (prevalentemente) e-mail. Un bug "esisteva" come thread, mettendo "[BUG REPORT] " o "LINUX BUG REPORT " nell'oggetto c'era una convenzione comune. Non c'erano ID di bug. Data la tipica base di utenti, una segnalazione di bug spesso veniva fornita con una patch. C'era uno strumento software dimenticato da tempo:ibug (vedi sotto), diverso da quello diff +patch .
Da Installazione di Linux 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 del 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 queste prime FAQ nella distribuzione Slackware 1.01:
VI.01) Sembra che $#@! i port su Linux non funzionano correttamente, cosa devo fare per segnalare i bug?
[...] Notare che il mio elenco di segnalazioni di bug "[email protected]" è stato gradualmente eliminato. Si scopre che Linux ha così pochi bug, la maggior parte 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 nel software con porting per Linux, di solito verrà risolto nel prossimo livello di patch o versione.
C'era la mailing list "linux-kernel" (che girava sull'originale vger ), newsgroup alt.os.linux, quindi comp.os.linux (che si è rapidamente diviso in una gerarchia nel 1993).
Questa prima FAQ su Linux (v1.11 Nov 1992) da comp.os.linux suggerisce anche di inviare un'e-mail direttamente a Linus.
Nel 1992 Matt Welsh (Esecuzione di Linux , Bibbia di Linux , TLDP) ha annunciato ibug per assistere nella generazione di segnalazioni di bug inviate tramite e-mail (ironicamente, non era possibile eseguirlo su Linux in quel momento poiché mancava una rete sufficiente per poter inviare un'e-mail).
Un modello di segnalazione di bug via email linux.temp veniva periodicamente pubblicato anche su comp.os.linux e gli aggiornamenti a una segnalazione di bug avevano un modello di aggiornamento linux.fix.temp .
C'era anche un repository di patch (FTP), per quanto posso dire questo era principalmente (non esclusivamente) per le patch ai programmi per il porting su Linux.
1993-1994
Le copie CVS dei sorgenti del kernel erano comuni, la prima che riesco a trovare è quella di Dirk Steinberg, dell'era kernal-0.99.14. Il primo annuncio che riesco a trovare è del gennaio 1993 sugli attivisti di Linux. Puoi ancora trovare copie archiviate (1994). Dirk ha anche mantenuto i binari cvs e il sorgente libc in CVS.
CVS non veniva utilizzato per tenere traccia dei bug nel senso contemporaneo, alcuni sviluppatori preferivano usarlo e le patch venivano spesso inviate sotto forma di differenze generate da cvs.
1995-1996
In questo periodo (ottobre 1995) David S. Miller iniziò a usare CVS per il port SPARC del kernel Linux (The Linux/SPARC port ). Nel febbraio 1996 diversi altri sviluppatori del kernel usavano indipendentemente CVS per tenere traccia delle patch, da linux-kernel questo thread e questo thread:Alan Cox, Stephen Tweedie, Kai Henningsen. (Il secondo thread riporta Russ Nelson che afferma in prima persona l'avversione di Linus per CVS.)
1997-1998
Nell'aprile 1998, poco dopo la nascita del secondo figlio di Linus, la questione del CVS si sollevò di nuovo, da linux-kernel vedi questo sotto-thread (Linus ribadisce direttamente le sue preoccupazioni su CVS).
Nel dicembre 1997, Andrew Tridgell ha rilasciato jitterbug, un bug tracker basato sul web. Nel giugno 1998 il "linux-patches" JitterBug era stato sostenuto su linux-kernel da Alan Cox. Questo è stato, per quanto ne so, il primo vero sistema di tracciamento dei bug utilizzato da Linus e altri sviluppatori chiave, purtroppo l'istanza "linux-patches" non è più online.
Nel settembre 1998, bitkeeper viene promosso per la prima volta su linux-kernel da Larry McEvoy.
1999 e successivi
Nel 1999/2000 le FAQ di lkml iniziarono a fare riferimento (D 1-16) all'albero CVS su (l'originale) vger. Ciò è stato sostenuto all'epoca da Andrew Tridgell.
Nel dicembre 2001, Jitterbug era caduto in disgrazia, vedi questo thread Linux-kernel, Linus, Alan Cox e molti altri sono stati 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 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 invettive Linus vintage).
Nell'aprile 2005 Linus annunciò l'allontanamento da BitKeeper, più o meno nel periodo in cui menzionò per la prima volta git per nome. Poco dopo che git divenne capace di auto-hosting, Linus smise di usare BitKeeper e iniziò a usare git per il kernel.
Nel dicembre 2008 è stato annunciato il patch tracker Patchwork per linux-kernel, un patch tracker basato sul Web indipendente da SCCS che si integra con le mailing list per tenere traccia di patch e follow-up. Il suo utilizzo continua ancora oggi, ci sono circa 40 liste monitorate in questo modo su https://patchwork.kernel.org/ , anche se non tutte sono attive.
Riferimenti
Riferimenti utili:
- L'essenza del lavoro distribuito:il caso del kernel Linux (Jae Yun Moon, Lee Sproull)http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (novembre 2000)
- Linee guida per la segnalazione di bug di Linux (luglio 1992)http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
- Archivio di 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 1995http://lkml.iu.edu/hypermail/linux/kernel/(purtroppo la prima email è del giugno 1995 in cui l'amministratore Chris Dent annuncia di aver perso gli archivi precedenti ...) L'archivio LKML risale solo al 1996
- Frammenti da linux-devel 1993-1994 da tsx11http://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 queste notizie sugli hacker thread (marzo 2015) con l'avvicinarsi del decimo anniversario di git:https://news.ycombinator.com/item?id=9263336
Posso dire come viene gestita la segnalazione dei bug per lo sviluppo di git stesso.
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 cercando negli archivi delle mailing list di git.
Non si tratta di "non abbiamo ancora trovato un bug tracker che sia 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 della lista di sviluppo.
La gestione dei bug ne fa parte e non sembra essere un compito banale gestire i bug in questo modo; Dipende certamente 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 articoli brevi. Per un esempio dallo sviluppo di git, vedi questo nel newsgroup gmane.comp.version-control.git mirroring della mailing list:Cosa bolle in pentola in git.git
Quello che posso dire con certezza:se hai un manutentore bravo in questo, funziona molto bene.
Ad esempio, sarei molto sorpreso se l'introduzione di un bug tracker ha avuto un effetto positivo sulla produttività sulle funzionalità implementate e sulla qualità, anche a lungo termine dopo l'ammortamento dell'overhead 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 centrale come con git. Esistono elenchi separati per argomenti secondari, come file system o networking.
Poiché ci sono argomenti separati, gestiti da sviluppatori per lo più separati, è possibile che alcuni gruppi utilizzino strumenti localmente per il proprio gruppo.