Ich wuerde mal sagen, dass dies in der letzten Woche schon ein wenig einer Invasion gleichkam. Nachdem es ja seit Ewigkeiten in Hin und Her in Sachen Einrichtung eines Issue-Trackers fuer LOFAR gab – urspruenglich mit dem Intention die Software-Entwicklung leiten zu koennen, nach und nach dann aber auch mit dem Hintergedanken jegliche Art von Aktivitaeten zu inventarisieren – so wollte und wollte einfach nichts geschehen. Es wuerde mir sicher ohne weiteres gelingen Dokumente oder Notizen ans Licht zu bringen, welche gut drei oder vier Jahre zurueckliegen, wo davon die Rede ist einen Bugtracker fuer die Entwicklung der User Software aufzusetzen. Mit der gewachsenen Menge an Teilprojekten und Aufgabenbereichen hat der Druck auf die Leute bei ASTRON – vorwiegend im Radio-Observatory (RO), welches ja fuer den laufenden Betrieb von LOFAR verantwortlichen zeichnen soll – zugenommen, endlich einmal eine Infrastruktur zu schaffen, ueber welche sich Meldungen und Aktivitaeten einreichen, mitverfolgend und buchhalten lassen. Den urspruenglichen Bestrebungen einiger Leute aus dem R&D Department, naemlich einfach den in Gebrauch befindlichen Bugzilla weiter aufzubohren und als Standard zu etablieren, haben vor allen Dingen Michael und ich eine ziemlich klares nein entgegengebracht, weil eigentlich ziemlich schnell klar war, dass diese Variante keinesfalls den Anspruechen genuegen wuerde. Es ist sicherlich eine Sache, wenn man es mit einer ueberschaubaren Gruppe qualifizierter Software-Entwickler zu tun hat, welche ein solches Tool fuer ihre Arbeit an einem Software-Project – dessen Zustand, moeglichen Fehlern, einer Roadmap fuer die zukuenftige Entwicklung, etc. – einsetzt; will man den Benutzerkreis aber ausweiten und dies dies zu einer Art Front-End machen, ueber welches eine breite Masse von Benutzern Rueckmeldungen, Fehlermeldungen, Beschwerden, Vorschlaege und so weiter einreichen sollen, dann hat man schon ein Handwerkzeug noetig, welches es ermoeglicht Informationen aufzubereiten, zu buendeln, zu kategorisieren, etc. Wie es aber leider nun mal traurige Tradition ist, so brauchen die Dinge eine ziemliche Weile ehe sich etwas bewegt. Nach der Bildung der “LOFAR Commissioning Coordination Group” (LCCG) im October letzten Jahres war es einer der meistgenannten Wuensche, dass endlich ein Issue Tracker zur Verfuegung gestellt wird; ich glaube es gibt kein LCCG Meeting seither, wo dieser Punkt nicht auf der Tagesordnung stand, ohne dass wirklich klar war, ob nun konkrete Schritte unternommen werden oder nicht. Das aenderte sich dann schliesslich kurz vor Weihnachten, als die Nachricht die Runde machte, dass es eine Testinstallation gaebe, welche wohl zu Beginn des neuen Jahres der Allgemeinheit zur Verfuegung gestellt werden wuerde; nach einiger Debatte war es auf die Loesung hinausgelaufen, welche wir sicherlich schon ein Jahr frueher vorgeschlagen hatten. Aber gut, das sein einfach Dinge, welche man kennt, wenn man eine Weile dabei ist.

Worauf ich mit dieser Vorgeschichte ja eigentlich hinaus wollte ist folgendes: nachdem eine ziemlich lange Zeit nichts passiert ist, sind in der vergangen Woche gleich drei Issue Tracker online gegangen:

  • Zum einen hatten wir da den lange angekuendigten Redmine-basierten Issue Tracker fuer LOFAR: ![Redmine LOFAR](/blog/2011/02/2011-02-16_redmine_lofar.png]] Der inzwischen bekannten Vorgehensweise folgend ist selbst der Lese-Zugriff alleine nach Anmeldung moeglich, eine Kleinigkeit in welcher sich schon die beiden Wikis unterschieden haben.
  • Zum zweiten hatten wir den – ebenfalls Redmine verwendenden – Issue-Tracker fuer AARTFAAC: Redmine AARTFAAC Ich glaube der wirklich passende Kommentar dazu stammt von John: “Today is Redmine Day! Mine is a pretty red colour and has a picture of Artie the Aardvark on it: I win! :-)” Als weitere Kategorie waere hier wahrscheinlich auch noch das laengste der Akronyme aufzulisten, aber da bin ich mir nicht ganz sicher, ob dies Teil des Wettstreites war.
  • Gegenueber den beiden anderen Trackern nimmt sich meine Seite auf Github – zumindest was die Absichten betrifft – ja schon recht bescheiden aus: Issues DAL Auch wenn es ein klein wenig Diskussion darueber gab, ob die Buchhaltung in Sachen DAL nun Teil des LOFAR Issue-Tracker sein sollte oder nicht, gab es doch ausreichend Argumente dafuer dies enger an den Code selber zu koppeln; schliesslich ist Teil der Hintergedanken fuer die Umstellungen der letzten Nacht ja, das die DAL eben nicht mehr allein ein Backend fuer LOFAR, sondern fuer ein breiter aufgestelltes Publikum gedacht ist.

Was nun natuerlich beginnen muss, ist das die Tracker wirklich ihre Arbeit aufnehmen und sich die Leute daran gewoehnen von ihnen Gebrauch zu machen. Auch wird es wohl noch eine kleine Weile Dauern, ehe die Anfangswehen ausgestanden sind (so hatte ich auch schon eine Diskussion mit Arno darueber welche Kategorien denn nun auf dem LOFAR Issue-Tracker eingerichtet werden sollten und welche nicht). Grundsaetzlich ist dies aber schon einmal eine gute Richtung, in welche sich die Dinge entwickeln.