© Diego Cervo, 123RF.com

Simple Defects macht für Bugs, was Git für Programmecode tut: Die Entwickler können sich eigene Kopien der Bugdatenbank ziehen, sie bearbeiten und mit anderen synchronisieren. Doch leider dümpelt die vielversprechende Software im Betastadium vor sich hin.

Dank verteilter Versionskontrollsysteme wie Git, Darcs oder Mercurial gehen Software-Entwickler flexibel mit Programmcode um: Sie spalten Zweige ab, arbeiten unterwegs mit einer lokalen Kopie auf dem Notebook und gleichen sie regelmäßig mit dem Repository des Maintainers ab. Ein anderes wichtiges Werkzeug des Software-Entwicklers benötigt dagegen immer noch eine zentrale Server-Instanz: der Bugtracker, etwa verkörpert durch Bugzilla oder Trac.

Dezentrales Zeitalter

Das freie Softwarepaket Simple Defects (SD) möchte dem ein Ende bereiten und das verteilte Modell auf die Bugdatenbank ausweiten. Die ursprüngliche Idee dazu stammt von Jesse Vincent und Chia-Liang Kao, Geschäftspartnern bei der US-Firma Best Practial, die den freien Request Tracker RT entwickelt hat. Die derzeitige Maintainerin ist die amerikanische MIT-Absolventin Christine Spang, die ihren Einstieg in die SD-Entwicklung während eines Praktikums fand.

SD [1] ist in Perl umgesetzt und fußt auf der verteilten Datenbank Prophet [2]. Die Macher empfehlen die Installation der beiden Komponenten aus dem aktuellen Git-Master [3]. SD verlangt eine Menge Perl-Module, denn die Entwickler haben im Code des Bugtrackers eine große Anzahl von Features angelegt, auch wenn diese derzeit nur rudimentär ausgeführt sind.

Alternativ lässt sich der Bugtracker aus einem Debian-/Ubuntu-Paket oder aus dem CPAN als Modul App::SD installieren. Dabei erhält der Anwender allerdings die Ausgabe 0.74 vom Januar 2010, die viele Nachbesserungen der Git-Version noch nicht enthält. Die Software steht unter MIT-Lizenz.

SD verwendet eine Kommandozeilen-Schnittstelle, die mit ihren einprägsamen Befehlen stark an Git und Konsorten erinnert. Hat der Anwender mit der Umgebungsvariablen »SD_REPO« den Speicherort für die Datenbank konfiguriert, legt er mit »sd init« seine Bugdatenbank an. Mit den »sd config« – und »sd settings« -Befehlen kann er zahlreiche Einstellungen vornehmen. Konfigurierbar sind unter anderem die Komponenten, Meilensteine und Bearbeitungszustände für das Projekt sowie Standardvorgaben für neu angelegte Tickets.

Das Kommando »sd ticket create« legt einen neuen Eintrag an, »sd ticket update Ticket-ID« ist für Änderungen zuständig, »sd ticket list« zeigt eine Übersicht der Bugs, »sd ticket show Ticket-ID« ein einzelnes Ticket inklusive seiner Historie (Abbildung 1). Zum Bearbeiten der Einträge kommt das in der Umgebungsvariablen »EDITOR« eingestellte Programm, etwa Vi oder Emacs, zum Einsatz. Daneben gibt es Take- und Give-Aktionen, um Bugs zuzuweisen, sowie weitere Operationen wie Schließen. Das eingebaute Hilfekommando »sd help Stichwort« gibt über alle Befehle Auskunft.

Abbildung 1: Die Befehle des SD-Kommandozeilen-Clients zum Auflisten und Anzeigen der Tickets erinnern an die Versionsverwaltung Git. Zum Bearbeiten der Einträge verwendet der Benutzer seinen Lieblingseditor.

Publizieren und Replizieren

Möchte ein Anwender seine Bugdatenbank anderen zugänglich machen, bietet SD ihm zwei Möglichkeiten: Bei der ersten kann er einen Schnappschuss seiner Tickets per »sd publish –to User@Host:Pfad« publizieren, wobei SD auf Rsync und SSH setzt. Damit andere darauf zugreifen können, muss allerdings ein Web- oder FTP-Server die so kopierten Dateien anbieten oder sie müssen über das Dateisystem erreichbar sein. Liegt die Kopie auf einem Webserver, lässt sie sich mit »sd clone –from http://Host/Pfad/replica« klonen, Aktualisierungen holt der Benutzer mit dem Befehl »sd pull –from http://Host/Pfad/replica« in seine lokale Instanz.

Glücklicherweise merkt sich SD die Adressen der einmal verwendeten Quell-Repositories, zudem kann der Anwender Kurznamen vergeben, sodass sich die Tipparbeit in Grenzen hält. Auch für ganze Kommandozeilen lassen sich Aliase anlegen, etwa um maßgeschneiderte Reports abzurufen. Konflikte legt das Tool in einem interaktiven Dialog zur Entscheidung vor. Ein Push-Kommando wie beispielsweise bei Git gibt es nicht, die SD-Benutzer sind auf das Pull-Verfahren eingeschränkt.

Bei der zweiten Veröffentlichungsmethode stellt die SD-Software die Daten über ihren eingebauten HTTP-Server zur Verfügung. Der Befehl »sd server –port Portnummer« startet den Server, bei Portnummern über 1024 sind dazu keine Linux-Rootrechte erforderlich. Klon- und Pull-Kommandos erfolgen wie oben, aber zuzüglich der Portnummer. Der SD-Server macht seine Dienste per Zeroconf Networking (bei Apple Bonjour genannt, [4]) im lokalen Netzwerk bekannt. Der Befehl »sd pull –local« findet diese Server-Instanzen und versucht deren Daten per Pull abzuholen.

Neben der Möglichkeit zum Synchronisieren bietet der SD-Server auch eine Weboberfläche für die Ticketdatenbank (Abbildung 2). Sie besitzt einen etwas kleineren Funktionsumfang als das Kommandozeilenprogramm und weist noch einige Bugs auf. SD erlaubt es zudem, die Bugs mit Kommentaren und Attachments zu versehen. Die Funktion zum Anhängen scheint aber vorrangig für Patches, Logs und andere Dateien im Plaintext-Format gedacht zu sein – der Test der Redaktion mit einem PDF-Dokument scheiterte jedenfalls.

Abbildung 2: Zum Publizieren der Bugdatenbank kann der Anwender den integrierten SD-Server starten. Dieser bietet die Ticketdaten per HTTP zum Synchronisieren an und zeigt eine Weboberfläche mit Eingabemöglichkeiten.

Noch nicht reif

Hier endet der Kern der Bugtracker-Software, dessen Reifegrad Christine Spang als Beta bezeichnet: “Wir bemühen uns, beim Core-Modul die Rückwärtskompatibilität zu gewährleisten. Die Synchronisation zwischen SD und SD dürfte in beide Richtungen zuverlässig sein.”

Für den Weg zu einer stabilen Version 1.0 gibt es derzeit weder Roadmap noch Termin. Vor allem fehle den Projektmitarbeitern Zeit, so Spang. Sie selbst arbeitet als Entwicklerin beim Startup Ksplice, das Software und Dienstleistungen rund um das gleichnamige Tool zum Patchen des Linux-Kernels anbietet.

Die Simple-Defects-Homepage listet einige unfertige Features auf, die die Software erst richtig interessant machen würden, darunter die Synchronisation mit anderen Issue-Trackern. Laut der Maintainerin befinden sich diese Schnittstellen derzeit im Alphastadium, wobei der Abgleich mit Best Practicals RT und mit Hiveminder am weitesten gediehen ist. Hier gibt es übrigens auch die ansonsten bei SD fehlende Push-Methode.

In Arbeit sind daneben noch Anbindungen an die Ticketsysteme von Trac, Github, Google Code und Redmine. Im aktuellen Zustand sind sie noch nicht zu gebrauchen, es gibt sogar unangenehme Überraschungen: Beim Import der Bugdatenbank aus einer passwortgeschützten Trac-Instanz beispielsweise speichert SD die Zugangsdaten im Klartext auf dem lokalen Rechner.

Reizvolle Ansätze

Für die Versionskontrollsysteme Git und Darcs existieren SD-Wrapper. Bei Projekten, die mit diesen Systemen verwaltet werden, sollen die Skripte die Bugdatenbank gleich dazupacken. Eine hervorragende Idee, die vielen Software-Entwicklern entgegenkommen dürfte. Tatsächlich steckt ein Aufruf von »git-sd« die Ticketdatenbank in das Verzeichnis ».git/sd/« , doch eine Funktion zum gemeinsamen Klonen von Code und Bugs hat offenbar noch niemand geschrieben.

Auch die Dokumentation fällt mit einer einzigen Wiki-Seite [5] noch recht dürftig aus. Die spärlichen Nachrichten auf der SD-Mailingliste unterstreichen, dass es dem Projekt an Manpower fehlt.