Perché alcuni grandi progetti, come Git e Debian, usano solo una mailing list e non un tracker di problemi?

Il tracker di bug per qualsiasi progetto di dimensioni decenti mi sembra un gioco da ragazzi: è davvero facile organizzare centinaia o migliaia di problemi, senza problemi che si scontrano o si confondono.

Quindi, quando vedo alcuni progetti davvero grandi, come Git, che utilizza una mailing list come metodo principale per coordinare la manutenzione e lo sviluppo, rimango un po 'stupito. Esempi:

• Git - Pagina della comunità :

  ... Le segnalazioni di bug devono essere inviate a questa mailing list.

• Sistema di tracciamento dei bug Debian , per Wikipedia:

  ... La sua caratteristica unica è che non ha alcuna forma di interfaccia web per modificare le segnalazioni di bug - tutte le modifiche sono fatte tramite e-mail.

Molti moderni tracker di bug hanno un'ottima integrazione con la posta elettronica (puoi ricevere commenti o notifiche sui bug che stai osservando o che ti vengono assegnati), nonché sui sistemi di controllo della versione (i commit possono essere contrassegnati come risoluzione di un problema, ecc. .). Gran parte di questo dovrebbe essere fatto manualmente con una mailing list e riceverai tonnellate di e-mail sui bug che non ti interessano.

Quindi quali sono i principali vantaggi di una mailing list rispetto a un bug tracker basato sul web? Perché alcuni grandi progetti usano solo una mailing list?

La preferenza che osservi sembra una conseguenza naturale della raccomandazione chiaramente indicata negli standard di codifica GNU . Suggerisce di segnalare i bug via e-mail, come puoi vedere nella citazione seguente (ho contrassegnato in grassetto la parte che indirizza direttamente le tue osservazioni):

4.7.2 --help

L' --helpopzione standard dovrebbe generare una breve documentazione su come richiamare il programma, sull'output standard, quindi uscire correttamente. Altre opzioni e argomenti dovrebbero essere ignorati una volta che questo è visto, e il programma non dovrebbe svolgere la sua normale funzione.

Verso la fine ‘--help’dell'output dell'opzione, inserire le righe che forniscono l'indirizzo e-mail per le segnalazioni di bug , la home page del pacchetto (normalmente ‘http://www.gnu.org/software/pkg’e la pagina generale per assistenza sull'utilizzo dei programmi GNU. Il formato dovrebbe essere così:

    Report bugs to: mailing-address
    pkg home page: <http://www.gnu.org/software/pkg/>
    General help using GNU software: <http://www.gnu.org/gethelp/>

Va bene menzionare altre mailing list e pagine Web appropriate.

Le preferenze sopra indicate, a loro volta, riflettono l'accettazione universale dell'e-mail come forma di comunicazione elettronica. Ogni utente che legge --helpmessaggi come suggerito sopra dovrebbe facilmente capire cosa fare se vede un bug: l'invio di messaggi è semplice.

Il tracker dei problemi potrebbe essere (e penso che lo sia ) migliore per uno sviluppatore che lavora nel progetto, ma per un pubblico più ampio sarebbe più difficile presentare e spiegare come usarlo, soprattutto tenendo conto della grande varietà e delle differenze tra i diversi sistemi di tracciamento dei problemi .

Un progetto può usare Bugzilla, un altro rimarrà con JIRA, il terzo con ... GNATS , ecc. Ecc. Ecc. Non c'è modo di presentare tutto questo "zoo" in modo standard e uniforme come

Report bugs to: mailing-address

Nota sopra non significa che i progetti non dovrebbero utilizzare il tracker dei problemi internamente . Come spiegato in un'eccellente risposta alla domanda correlata ,

Il tuo bug tracker è per tua comodità, non per quello dei tuoi clienti. Se non riesci a preoccuparti di accettare il problema del telefono o della posta elettronica e inserirlo da solo, come pensi che si sentano?

Devi essere in grado di inserire i problemi e assegnarli manualmente a un client ...

Con Git, in particolare, esiste un semplice motivo storico: Git è stato avviato da hacker Linux per hacker Linux e utilizza lo stesso modello di sviluppo e gli stessi strumenti di Linux stesso. Linux, tuttavia, è più vecchio del WWW, quindi, quando Linux è stato avviato non semplicemente c'erano issue tracker web-based, perché non vi era alcuna web!

Di conseguenza, la comunità Linux ha sviluppato strumenti e flussi di lavoro estremamente efficienti per gestire le segnalazioni di bug e le revisioni del codice tramite e-mail, e non c'era motivo per cui buttare via tutto quel lavoro e ricominciare da capo quando hanno iniziato il progetto Git.

Per Git:

Ci sono diverse discussioni sulla mailing list in cui le persone propongono di utilizzare un qualche tipo di bug tracker. Queste iniziative sembrano essersi esaurite, quindi il motivo per cui Git non utilizza un tracker di bug è probabilmente semplicemente che la maggior parte dei collaboratori non lo trova utile.

In un post nella mailing list , Junio ​​C Hamano (manutentore di Git) ha riassunto il motivo per cui ritiene che un localizzatore di bug non sia molto utile. Non voglio includere l'intero post (è piuttosto lungo), ma si riduce a:

• Se stai solo cercando informazioni su problemi risolti, la ricerca negli archivi dell'elenco funziona allo stesso modo della ricerca di un bug tracker.
• Se si segnala un bug genuino e le persone vogliono occuparsene, anche l'elenco funziona bene.
• Se nessuno è interessato a lavorare su un problema, cadrà attraverso le fessure, anche in un bug tracker.
• Un inseguitore di bug sarebbe un altro sistema che deve essere mantenuto, controllato regolarmente per nuovi bug, chiuso bug corretti ecc., In breve, lavoro extra per pochi benefici.

Debian usa un tracker di bug, la sua interfaccia predefinita è e-mail. Ed è conveniente. Lucas Nussbaum, attuale Project Leader Debian, ha pubblicato alcuni giorni fa :

debbugs è il software dietro il Debian Bugs Tracking System (BTS). È anche usato dal progetto GNU. Nonostante sia spesso percepito come vecchio stile, presenta diverse funzionalità uniche, come il monitoraggio dello stato dei bug in ogni versione e ramo di un pacchetto) o la capacità di eseguire tutte le interazioni via e-mail, rendendo molto facile il lavoro offline o in ambienti scarsamente connessi.

L'ultima parte è una funzione killer qui - basta mettere in coda quei rapporti nella coda di posta locale fino a quando non scendi dall'aereo!

• Tiene fuori i bambini di 9 anni.
• Non è necessario creare un account separato per ciascun forum.
• [minore] Esperienza utente coerente su diverse mailing list e una curva di apprendimento pari a zero quando si abbona a un nuovo elenco.
• Funziona offline. potresti connetterti a Internet e scaricare una serie di mail, quindi fare escursioni, scrivere le tue risposte mentre ti godi la madre natura e inviarle in seguito.
• Consente la crittografia e / o la firma della posta tramite GPG.
• Decentrato - Se il forum si arresta in modo anomalo, avresti comunque una copia, è anche a prova di manomissione, un moderatore / hacker malvagio non può facilmente manomettere ciò che hai detto. Nessuno può annullare la cronologia.
• Consente filtri, cartelle e tutte le funzionalità organizzative avanzate di un client di posta elettronica.
• "Notifiche push": puoi lasciare aperto il tuo client di posta elettronica e ricevere notifiche di nuove risposte.
• Un posto dove dominarli tutti: non c'è bisogno di saltare tra siti diversi.
• Immunità a tutte le vulnerabilità di sicurezza che coinvolgono il web (html / javascript / iniezioni, ecc.)
• No bloat - Nessun badge, firme in movimento, annunci pubblicitari, web beacon, bloat javascript. È tutto semplice e al punto - discussione.
• Meno carico del server rispetto a una configurazione LAMP.

Uno svantaggio delle mailing list che viene in mente è che i forum sono divisibili in categorie e sottocategorie mentre le mailing list no. Questo può essere emulato dividendo una mailing list in diverse mailing list, quindi gli utenti possono utilizzare i filtri appropriati per inserire ogni messaggio con la sua cartella corrispondente (ogni cartella è una categoria). Nei forum Web, questo è automatico.