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

La preferenza che osservi sembra una conseguenza naturale della raccomandazione chiaramente enunciata in Norme di codifica GNU . Suggerisce di segnalare bug via email, come puoi vedere nella citazione di seguito (ho contrassegnato grassetto la parte che indirizza direttamente le tue osservazioni):

4.7.2 --help

The standard --help option should output brief documentation for how to invoke the program, on standard output, then exit successfully. Other options and arguments should be ignored once this is seen, and the program should not perform its normal function.

Near the end of the ‘--help’ option’s output, please place lines giving the email address for bug reports, the package’s home page (normally ‘http://www.gnu.org/software/pkg’, and the general page for help using GNU programs. The format should be like this:

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

It is ok to mention other appropriate mailing lists and web pages.

Preferibilmente, a sua volta, riflette l'accettazione universale dell'email come forma di comunicazione elettronica. Ogni utente che legge% messaggio di--help come suggerito sopra dovrebbe semplicemente capire cosa fare se vede un bug - la spedizione è facile.

Il tracker dei problemi potrebbe essere (e penso che sia ) migliore per uno sviluppatore che lavora nel progetto, ma per un pubblico più ampio sarebbe più difficile presentare e spiegare come usarlo, tenendo in particolare conto ampia varietà di account e differenze tra i diversi sistemi di rilevamento dei problemi .

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

Report bugs to: mailing-address

Nota sopra non significa che i progetti non dovrebbero usare il internamente . Come spiegato in un eccellente risposta alla domanda correlata ,

Your bug tracker is for your convenience, not your customers'. If you can't be bothered to take their phone or email issue and enter it yourself, how do you think they feel?

You need to be able to enter issues and assign them manually to a client...

Con Git, in particolare, esiste una semplice ragione storica: Git è stato avviato dagli hacker di Linux per gli hacker di Linux e utilizza lo stesso modello di sviluppo e gli stessi strumenti di Linux. Linux, tuttavia, è più vecchio del WWW, quindi, quando Linux è stato avviato, semplicemente non c'erano tracker di rilascio basati sul web, perché non c'era web!

Di conseguenza, la comunità Linux ha sviluppato strumenti e flussi di lavoro estremamente efficienti per gestire segnalazioni di bug e recensioni di codice via e-mail, e non c'era motivo per loro di buttar via tutto quel lavoro e ricominciare da capo quando hanno iniziato il lavoro Progetto Git.

Per Git:

Ci sono diverse discussioni sulla mailing list in cui le persone propongono di utilizzare una sorta di bug tracker. Sembra che tutte queste iniziative siano state vanificate, quindi la ragione per cui Git non usa un bug tracker è probabilmente semplicemente che la maggior parte dei contributori non la trova utile.

In un post alla mailing list , Junio C Hamano (manutentore di Git) riassume perché ritiene che un bug tracker non sia molto utile. Non voglio includere l'intero post (è piuttosto lungo), ma si riduce a:

• Se stai cercando solo informazioni sui problemi risolti, la ricerca negli archivi di elenchi funziona altrettanto bene come cercare un bug tracker.
• Se segnali un bug reale e la gente vuole prendersene cura, l'elenco funziona anche bene.
• Se nessuno è interessato a lavorare su un problema, cadrà nelle fessure, anche in un bug tracker.
• Un bug tracker sarebbe un altro sistema che deve essere mantenuto, controllato regolarmente per nuovi bug, risolto bug chiusi ecc., in breve, lavoro extra per poco beneficio.

Debian usa un bug tracker, la sua interfaccia predefinita è l'email. Ed è conveniente. Lucas Nussbaum, attuale capo progetto Debian, pubblicato qualche giorno fa :

debbugs is the piece of software behind the Debian Bugs Tracking System (BTS). It is also used by the GNU project. Despite often being perceived as old-style, it features several unique features, such as the tracking of the status of bugs in each version and branch of a package ), or the ability to perform all interactions via email, making it very easy to work offline or in poorly-connected environments.

L'ultima parte è una caratteristica killer qui: basta accodare quei rapporti nella tua coda di posta locale fino a quando non sei sceso dall'aereo!

• Mantiene i bambini di 9 anni.
• Non è necessario creare un account separato per ogni forum.
• [minore] Esperienza utente coerente tra diverse mailing list e una curva di apprendimento pari a zero quando si sottoscrive un nuovo elenco.
• Funziona offline. è possibile connettersi a Internet e scaricare un batch di posta elettronica, quindi fare escursioni, scrivere le risposte mentre si sta godendo la madre natura e inviarli in seguito.
• Consente la crittografia e / o la firma della posta tramite GPG.
• Decentrato - Se il forum si blocca, avresti ancora una copia, lo è anche a prova di manomissione, un moderatore / hacker malvagio non può facilmente manomettere con quello che hai detto. Nessuno può annullare la cronologia.
• Consente filtri, cartelle e tutte le funzionalità organizzative avanzate di a Email client.
• "Notifiche push": puoi lasciare aperto il tuo client di posta elettronica e ottenere notifiche di nuove risposte.
• Un posto per domarli tutti: non c'è bisogno di passare da un sito all'altro.
• Immune a tutte le vulnerabilità della sicurezza che coinvolgono il web (html / javascript / injection, ecc.)
• Nessun rigonfiamento - nessun badge, fantasia di firme in movimento, pubblicità, web beacon, javascript bloat. È tutto semplice e al punto - discussione.
• Minore carico del server rispetto all'impostazione 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, e quindi gli utenti possono usare i filtri appropriati per mettere ogni messaggio con la sua cartella corrispondente (ogni cartella è una categoria). Nei forum Web, questo è automatico.