Freie Bugtracker
Unabhängig davon welchen Bugtracker ein Projekt benutzt: es wird
immer Entwickler geben, die oft und gerne etwas daran auszusetzen haben.
Das scheint in Bezug auf Bugtracker häufiger zuzutreffen,
als bei irgend einem anderen der üblichen Entwicklungswerkzeuge.
Ich denke das liegt daran, dass Bugtracker so visuell und interaktiv
sind, dass es leicht ist, sich die Verbesserungen vorzustellen die man
vornehmen würde (wenn man nur die Zeit hätte), und diese
Verbesserungen auch laut zu benennen. Nehmen Sie die Verbesserungen mit
einem gewissen Vorbehalt – viele der hier aufgeführten Bugtracker
sind ziemlich gut.
In dieser Auflistung wird das Wort "Ticket" benutzt, um Einträge
in dem Tracker zu bezeichnen. Denken Sie aber daran, dass jedes System
seine eigene Begriffen verwenden kann, wobei der Begriff etwas wie
"Issue", "Artifact", "Bug" oder etwas anderes sein könnte.
Hinweis: Dieser Überblick stammt größtenteils noch aus dem
Jahre 2005, seitdem wurden einige neue Open-Source-Bugtracker geschrieben.
So könnten wir die Liste sicherlich einmal aktualisieren, aber bis dahin
erhalten Sie aktuelle Informationen unter
,
,
und
Redmine –
Redmine ist ein relativ junges (Stand 2011) und recht ausgefeiltes
Projekt-Management-System. Es geht etwas über einen Bugtracker hinaus,
denn es bietet auch Wikis, Diskussionsforen und andere Funktionen, dennoch
scheint die Fehlerverfolgung sein Kernstück darzustellen. Es hat eine
ziemlich intuitive webbasierte Benutzerschnittstelle, flexible
Konfiguration (mehr als ein Projekt, rollenbasierte Zugriffskontrolle,
benutzerdefinierte Felder usw.), Gantt-Diagramme, Kalender, bidirektionale
E-Mail-Interktion und mehr. Wenn Sie ein neues Projekt beginnen würden
und den Bugtracker frei wählen könnten, dann wäre Redmine eine gute
Wahl.
Bugzilla –
Bugzilla ist sehr verbreitet, wird aktiv entwickelt und scheint
seine Nutzer ziemlich glücklich zu machen. Ich benutze eine angepasste
Variante bei meiner Arbeit seit mittlerweile vier Jahren, und ich mag es.
Man kann es nicht sonderlich individualisieren, aber auf eine
gewisse Art kann das als Vorteil betrachtet werden:
Bugzilla-Installationen neigen so zu einem recht ähnlichem Aussehen,
und da viele Entwickler bereits mit der Bedienoberfläche vertraut sind,
fühlen sich auf gewohntem Terrain.
GNATS –
GNU GNATS ist einer der ältesten Open-Source-Butracker und
weit verbreitet. Seine größten Vorteile sind die Vielfalt seiner
Bedienung (er kann nicht nur durch den Browser sondern auch per
E-Mail oder über Kommandozeile bedient werden) und die Speicherung
der Tickets im Klartext. Die Tatsache, dass alle Daten der Tickets als
Textdateien gespeichert werden, erleichtert es, eigene Programme zu
schreiben, um die Daten analysieren und zu verarbeiten (zum Beispiel um
Statistiken zu erstellen). GNATS kann E-Mails auch auf verschiedene
Arten automatisch annehmen und sie den entsprechenden Tickets
hinzufügen, was auf Grundlage von Mustern in den E-Mail-Headern geschieht,
das erleichtert die Protokollierung des Austauschs zwischen Nutzern
und Entwicklern.
RequestTracker (RT) –
Auf der Webseite von RT steht "RT ist ein für Unternehmen geeignetes
Ticket-System, welches einer Gruppe von Personen erlaubt, Aufgaben,
Probleme und Anfragen die von einer Gemeinschaft von Nutzern eingereicht
werden, intelligent und effizient zu verwalten", womit das Wesentliche
gesagt ist. RT hat eine relativ ausgefeiltes Webinterface, und scheint
ziemlich weit verbreitet zu sein. Die Optik der Oberfläche wirkt zunächst
etwas komplex, bedarf aber lediglich einer Eingewöhnungsphase.
RT ist unter der GNU GPL lizenziert (aus irgend einem Grund
wird das auf der Webseite nicht recht deutlich).
Trac –
Trac ist etwas mehr als ein Butracker: es ist in Wirklichkeit ein
integriertes System von Wiki und Bugtracker. Es nutzt Wikiverweise
um Tickets, Dateien, Changesets der Versionsverwaltung, und einfache
Wikiseiten miteinander zu verbinden. Es ist recht einfach einzurichten,
und lässt sich mit Subversion integrieren (siehe ).
Roundup –
Roundup ist relativ einfach zu installieren (es wird lediglich
Python 2.1 oder höher benötig) und einfach zu benutzen. Es kann per
Browser, E-Mail oder Kommandozeile bedient werden. Die Vorlagen
für Ticket-Daten und die Webinterface können genauso angepasst
werden, wie Teile seiner Logik für die Übergänge zwischen verschiedenen
Zuständen.
Mantis –
Mantis ist ein Web-basierter Bugtracker, geschrieben in PHP, der
MySQL als Datenbanksystem nutzt. Es hat die Funktionen, die man erwartet.
Ich perönlich finde die Oberfläche sauber, intuitiv, und angenehm für die
Augen.
Flyspray –
Flyspray ist ein in PHP geschriebener Bugtracker. Seine Webseite
beschreibt es als "unkompliziert", und die Liste seiner Funktionen
beinhaltet: Unterstützung für mehrere Datenbanken (derzeit MySQL und
PGSQL); mehrere Projekte; 'Beobachtung' von Aufgaben, mit
Benachrichtigung bei Änderungen (mittels E-Mail oder Jabber); umfassende
Historie von Aufgaben; CSS-Themes; Datei-Anhänge; erweiterte
Suchfunktionen (aber auch einfach zu bedienende); RSS-/Atom-Kanäle;
Wiki und Klartext-Eingabe; Abhängigkeitsdiagramme.
Scarab –
Scarab ist als hochgradig anpassbarer, vollständiger Bugtracker
gedacht, mehr oder weniger die Vereinigung aller Funktionen die
von anderen Bugtrackern angeboten werden: Daten-Eingabe, Abfragen,
Berichte, Benachrichtigungen an interesierte Parteien,
gemeinschaftliches Sammeln von Kommentaren und Verfolgung von
Abhängigkeiten.
Es ist über administrative Webseiten anpassbar. Sie können in
einer einzigen Scarab-Installation mehrere aktive "Module" (Projekte)
haben. Innerhalb eines Moduls können Sie neue Arten von Tickets anlegen
(Mängel, Verbesserungen, Aufgaben, Support-Anfragen, usw.) und
beliebige Attribute hinzufügen, um den Tracker an die spezifischen
Erfordernisse ihres Projekts anzupassen.
Ende 2004 näherte sich Scarab seiner 1.0-Version.
Debian Bug Tracking System (DBTS) –
Das Debian-Bugtracking-System ist insofern ungewöhnlich, als dass
alle Eingaben und Änderungen per E-Mail gemacht werden: Jedes Ticket
bekommt seine eigene Mailadresse. Das DBTS skaliert ziemlich gut: hat zum Beispiel 277,741 Tickets.
Da die Bedienung über gewöhnliche E-Mail-Anwendungen erfolgt, eine
Umgebung mit der die meisten Personen vertraut sind und zu der sie leicht
Zugang haben, ist das DBTS geeignet für die Handhabung großer Mengen
eingehender Meldungen, die eine schnelle Klassifizierung und Reaktion
benötigen. Es gibt natürlich auch Nachteile. Entwickler müssen Zeit
investieren, um das Befehlssystem zu lernen, und Nutzer müssen ihre
Bug-Meldungen
ohne ein Web-Formular eingeben, das sie beim Schreiben in der Auswahl
der nötigen Informationen unterstützen würde. Es gibt Programme, die den
Nutzern zu helfen, bessere Bug-Meldungen zu schreiben, wie das
Kommandozeilenprogramm reportbug oder das
debbugs-el-Paket für Emacs. Die meisten Leute
werden diese Werkzeuge aber nicht benutzen; sie werden die E-Mail einfach
per Hand schreiben, und so werden sie die Richtlinien, die für die
Meldung von Bugs von Ihrem Projekt erarbeitet wurden, befolgen oder
eben auch nicht.
DBTS hat ein Webinterface mit reinem Lesezugriff, um Tickes
anzuschauen und abzufragen.
Trouble-Ticket Tracker
Solche Systeme sind eher darauf ausgelegt, Tickets für einen
Informationsschalter zu überwachen, als Bugs in Software. Sie werden
wahrscheinlich einen gewöhnlichen Bugtracker hilfreicher finden. Solche
Systeme habe ich hier der Vollständigkeit halber aufgeführt, da auch
auch ungewöhnliche Projekte vorstellbar sind, bei dem ein
Trouble-Ticket-System besser passt als ein herkömmlicher
Bugtracker.
WebCall –
Bluetail Ticket Tracker (BTT) –
BTT liegt irgendwo zwischen Trouble-Ticket-Tracker und
Bugtracker. Es bietet Funktionen für den Datenschutz, was
unter Open-Source-Bugtrackern etwas ungewöhnlich ist: Nutzer des Systems
werden in Mitarbeiter, Freunde, Kunden, oder Anonyme eingeteilt, und
es stehen, je nachdem zu welcher Kategorie man gehört, mehr oder weniger
Daten zur Verfügung. Es bietet etwas E-Mail-Integration, die Bedienung
mittels Kommandozeile und Mechanismen um E-Mails in Tickets umzuwandeln.
Es hat auch Funktionen zur Pflege von Informationen, die
nicht mit einem spezifischen Ticket zu tun haben, wie z.B. interne
Dokumentation oder FAQs.