Warum verwenden einige große Projekte, wie Git und Debian, nur eine Mailingliste und keinen Issue Tracker?

Der Bug-Tracker für ein Projekt mit vernünftiger Größe scheint mir ein Kinderspiel zu sein - er macht es wirklich einfach, Hunderte oder Tausende von Problemen zu organisieren, ohne dass Probleme kollidieren oder durcheinander geraten.

Wenn ich also einige wirklich große Projekte wie Git sehe, die eine Mailingliste als Hauptmethode für die Koordination von Wartung und Entwicklung verwenden, bin ich ein bisschen überwältigt. Beispiele:

• Git - Community Seite:

  ... Fehlerberichte sollten an diese Mailingliste gesendet werden.

• Debian-Bug-Tracking-System , per Wikipedia:

  ... Sein einzigartiges Merkmal ist, dass es keine Web-Oberfläche zum Bearbeiten von Fehlerberichten gibt - alle Änderungen erfolgen per E-Mail.

Viele moderne Bug - Tracker lassen sich sehr gut in E - Mails integrieren (Sie können Kommentare oder Benachrichtigungen über beobachtete oder Ihnen zugewiesene Fehler erhalten) sowie in Versionskontrollsysteme (Commits können als Lösung eines Problems markiert werden, usw.) .). Vieles davon müsste manuell mit einer Mailingliste erledigt werden, und Sie erhalten Unmengen von E-Mails über Fehler, an denen Sie nicht interessiert sind.

Was sind die Hauptvorteile einer Mailingliste gegenüber einem webbasierten Bug-Tracker? Warum verwenden einige große Projekte nur eine Mailingliste?

Die Präferenz, die Sie beobachten, scheint eine natürliche Folge der Empfehlung zu sein, die in den GNU Coding Standards klar angegeben ist . Es wird empfohlen, Fehler per E-Mail zu melden, wie Sie im folgenden Zitat sehen können (ich habe den Teil, der Ihre Beobachtungen direkt anspricht, fett markiert ):

4.7.2 --help

Die Standardoption --helpsollte eine kurze Dokumentation zum Aufrufen des Programms in der Standardausgabe ausgeben und anschließend erfolgreich beendet werden. Andere Optionen und Argumente sollten ignoriert werden, sobald dies angezeigt wird, und das Programm sollte seine normale Funktion nicht mehr ausführen.

Am Ende der ‘--help’Ausgabe der Option platzieren Sie bitte Zeilen mit der E-Mail-Adresse für Fehlerberichte , der Homepage des Pakets (normalerweise ‘http://www.gnu.org/software/pkg’und der allgemeinen Seite für die Hilfe bei der Verwendung von GNU-Programmen). Das Format sollte folgendermaßen aussehen:

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

Es ist in Ordnung, andere geeignete Mailinglisten und Webseiten zu erwähnen.

Diese Präferenz spiegelt wiederum die allgemeine Akzeptanz von E-Mails als Form der elektronischen Kommunikation wider. Jeder Benutzer, der eine --helpNachricht wie die oben vorgeschlagene liest , sollte leicht verstehen, was zu tun ist, wenn er einen Fehler entdeckt - Mailing ist einfach.

Der Issue-Tracker ist möglicherweise (und meiner Meinung nach ) besser für einen Entwickler, der an dem Projekt arbeitet. Für ein breiteres Publikum ist es jedoch schwieriger, ihn vorzustellen und zu erläutern, insbesondere unter Berücksichtigung der großen Vielfalt und Unterschiede zwischen den verschiedenen Issue-Tracking-Systemen .

Ein Projekt kann Bugzilla verwenden, ein anderes bleibt bei JIRA, das dritte bei ... GNATS usw. usw. usw. Es gibt einfach keine Möglichkeit, diesen "Zoo" so einheitlich und einheitlich wie möglich zu präsentieren

Report bugs to: mailing-address

Hinweis oben bedeutet nicht, dass Projekte den Issue Tracker nicht intern verwenden sollten . Wie in einer ausgezeichneten Antwort auf verwandte Frage erklärt ,

Ihr Bug-Tracker dient Ihrer Bequemlichkeit, nicht der Ihrer Kunden. Wenn Sie sich nicht die Mühe machen müssen, das Telefon- oder E-Mail-Problem selbst zu übernehmen, wie fühlen sich die beiden?

Sie müssen in der Lage sein, Probleme einzugeben und sie manuell einem Kunden zuzuweisen ...

Insbesondere bei Git gibt es einen einfachen historischen Grund: Git wurde von Linux-Hackern für Linux-Hacker gestartet und verwendet dasselbe Entwicklungsmodell und dieselben Tools wie Linux. Linux ist jedoch älter als das WWW. Als Linux gestartet wurde, gab es einfach keine webbasierten Issue Tracker, weil es kein Web gab!

Infolgedessen hat die Linux-Community äußerst effiziente Tools und Workflows für den Umgang mit Fehlerberichten und Codeüberprüfungen per E-Mail entwickelt, und es gab keinen Grund für sie, all diese Arbeiten wegzuwerfen und bei Null anzufangen, als sie das Git-Projekt starteten.

Für Git:

Es gibt mehrere Diskussionen auf der Mailingliste, bei denen Leute vorschlagen, eine Art Bug-Tracker zu verwenden. Diese Initiativen scheinen alle ins Wanken geraten zu sein. Der Grund, warum Git keinen Bug-Tracker verwendet, liegt wahrscheinlich einfach darin, dass die meisten Mitwirkenden ihn nicht nützlich finden.

In einem Beitrag zur Mailingliste fasste Junio ​​C Hamano (Betreuer von Git) zusammen, warum er der Meinung ist, dass ein Bug-Tracker nicht sehr nützlich ist. Ich möchte nicht den ganzen Beitrag einschließen (es ist ziemlich lang), aber es läuft auf Folgendes hinaus:

• Wenn Sie nur nach Informationen zu gelösten Problemen suchen, funktioniert das Durchsuchen der Listenarchive genauso wie das Durchsuchen eines Bug-Trackers.
• Wenn Sie einen echten Fehler melden und die Leute sich darum kümmern möchten, funktioniert die Liste auch gut.
• Wenn niemand daran interessiert ist, an einem Problem zu arbeiten, fällt es selbst in einem Bug-Tracker durch die Risse.
• Ein Bug-Tracker wäre ein weiteres System, das gewartet, regelmäßig auf neue Fehler überprüft, behobene Fehler geschlossen usw. werden müssen, kurz, zusätzliche Arbeit für geringen Nutzen.

Debian verwendet einen Bug-Tracker, seine Standardoberfläche ist E-Mail. Und es ist bequem. Lucas Nussbaum, aktueller Debian-Projektleiter, hat vor ein paar Tagen folgendes gepostet :

debbugs ist die Software hinter dem Debian Bugs Tracking System (BTS). Es wird auch vom GNU-Projekt verwendet. Obwohl es oft als altmodisch angesehen wird, bietet es einige einzigartige Funktionen, wie die Verfolgung des Status von Fehlern in jeder Version und jedem Zweig eines Pakets, oder die Möglichkeit, alle Interaktionen per E-Mail durchzuführen, was die Arbeit sehr erleichtert offline oder in schlecht verbundenen Umgebungen.

Der letzte Teil ist ein Killerfeature - reihen Sie diese Berichte einfach in Ihre lokale Mail-Warteschlange ein, bis Sie aus dem Flugzeug gestiegen sind!

• Hält 9-Jährige fern.
• Es muss kein separates Konto für jedes Forum erstellt werden.
• [minor] Konsistente Benutzererfahrung über verschiedene Mailinglisten hinweg und keine Lernkurve beim Abonnieren einer neuen Liste.
• Funktioniert offline. Sie könnten eine Verbindung zum Internet herstellen und eine Reihe von E-Mails herunterladen, dann wandern, Ihre Antworten schreiben und die Natur genießen und sie später senden.
• Ermöglicht das Verschlüsseln und / oder Signieren von E-Mails über GPG.
• Dezentralisiert - Wenn das Forum abstürzt, hätten Sie immer noch eine Kopie. Es ist auch manipulationssicher. Ein böser Moderator / Hacker kann nicht einfach an Ihren Aussagen manipulieren. Niemand kann die Geschichte ungeschehen machen.
• Ermöglicht Filter, Ordner und alle erweiterten Organisationsfunktionen eines E-Mail-Clients.
• "Push-Benachrichtigungen" - Sie können Ihren E-Mail-Client geöffnet lassen und Benachrichtigungen über neue Antworten erhalten.
• Ein Ort, um alle zu regieren - Sie müssen nicht zwischen verschiedenen Standorten wechseln.
• Immun gegen alle Sicherheitslücken im Web (HTML / Javascript / Injection, etc.)
• Kein Aufblähen - Keine Abzeichen, ausgefallene bewegliche Signaturen, Anzeigen, Web Beacons, Javascript aufblähen. Es ist alles einfach und auf den Punkt - Diskussion.
• Geringere Serverlast als bei einem LAMP-Setup.

Ein Nachteil von Mailinglisten ist, dass Foren in Kategorien und Unterkategorien unterteilt werden können, Mailinglisten jedoch nicht. Dies kann emuliert werden, indem eine Mailingliste in mehrere Mailinglisten unterteilt wird. Anschließend können Benutzer die entsprechenden Filter verwenden, um jede Nachricht in den entsprechenden Ordner zu verschieben (wobei jeder Ordner eine Kategorie ist). In Webforen erfolgt dies automatisch.