kirjoittaessani

Jetzt ist also Firefox der letzte größere Community-Browser.

Tschüß, Camino. Es war schön mit Dir.

Vor ein paar Wochen hatte ich von Gitzilla berichtet, das aus git-Commits automatisch Bugzilla-Kommentare generiert. Gestern ist mir eine neue Idee gekommen. Dazu muß ich aber etwas weiter ausholen.
Ein Rechencluster funktioniert ein bisschen wie eines von den ganz alten Rechenzentren. Dort hat man sein Programm in Form eines Stapels Lochkarten abgegeben. Wenn ein Rechner frei wurde, hat ein RZ-Mitarbeiter (Operator) den Stapel abarbeiten lassen, und das Ergebnis wurde vom Schnelldrucker ausgegeben, so daß man es sich später abholen konnte.
Heutzutage ist der Lochkartenstapel einer Datei gewichen, die Aufgabe des Operators hat eine Software namens Batch-System übernommen, und die Ausgabe landet statt auf dem Schnelldrucker auf der Festplatte -- aber das Prinzip ist gleich geblieben, interaktives Arbeiten wie auf dem PC am Arbeitsplatz gibt es hier nicht.
Unser Cluster ist meist bis zum Anschlag voll mit Jobs, aber gelegentlich sind doch einige Nodes frei -- besonders die älteren haben nicht immer voll zu tun. Weil Strom teuer ist,1 haben wir ein Lights-Out-Management, das unbenutzte Nodes abschaltet.2
Idealerweise sollte das vom Batchsystem erledigt werden, denn das ist die Instanz, die am besten weiß, welche Sorte Nodes wann in welcher Zahl benötigt wird. Die SGE kann das aber nicht, und so läuft bei uns ein externes System. Neben dem bloßen Ein- und Ausschalten nach Bedarf kann es auch noch ein paar weitere Sachen, zum Beispiel kann man defekte Nodes als "poweroff" markieren.
Das Lightsout-Management solche Nodes dann für neue Jobs, wartet ab, bis die aktuellen abgearbeitet sind, und schaltet die Node dann ab. Jetzt kann sich einer der Kollegen an die Reparatur machen -- wenn er merkt, das die Node aus ist.
Da wäre es doch schön, Lightsout und Bugzilla so zu integrieren, das eine Meldung über das Abschalten gleich in dem Bug erscheint, der für die defekte Node angelegt worden ist. Ich habe große Teile des heutigen Tages damit verbracht, eine sinnvolle Implementation dazu zu finden -- aber viel gebracht hat das nicht, außer, daß ich einiges über Web-Services gelernt habe. Die Kurzform geht ungefähr so: es gibt verschiedene Protokolle, z.B. JSON, REST, XML/rpc und SOAP. Leider unterstützt Bugzilla nur JSON und XML/rpc, für Ada habe ich aber nur eine Bibliothek für SOAP gefunden.3 Da ist wohl eine Eigenentwicklung angesagt. Look for me on Github. Mal sehen, wie aufwendig das wird.

1. typischerweise erreichen die Stromkosten über drei Jahre Dauerbetrieb den Anschaffungspreis [↩]
2. und bei Bedarf natürlich auch wieder an [↩]
3. Und REST? Mir schwirrt schon der Kopf [↩]

(Hinweis: der Artikel ist sicher leichter zu verstehen, wenn man sich die Grafik auf Vincents Seite daneben legt)

Nachdem ich Gitflow nun einige Zeit in mehreren Projekten verwendet habe, möchte ich noch ein paar Dinge berichten, die mir aufgefallen sind. Zur Erinnerung: Man benutzt mehrere Zweige,1 die nebeneinanderher laufen. Neben develop, auf dem die Entwicklung vorangetrieben wird, gibt es master, der nur veröffentlichte Versionen2 enthält, Feature-Zweige (auf denen größere Neuerungen entwickelt werden; ein Zweig pro Feature), Hotfixes3 und Releases.4

Man kann zwar mehrere Feature-Zweige gleichzeitig offen haben, um einen neuen Hotfix- oder Release-Zweig zu starten, muß der vorhergehende aber abgeschlossen werden. Das war zunächst etwas schwer verdaulich für mich, ist aber letztlich sicher sinnvoll: Releases folgen aufeinander, sie können nicht parallel laufen; eigentlich könnte man auch mit einem einzigen Release-Zweig leben, nur wird dann das Tagging schwieriger. Für Hotfixes gilt das nicht so eindeutig, aber git flow verwendet einen Hotfix-Zweig pro Version, nicht einen pro zu behebenden Bug.

Heute habe ich dann etwas Dummes gemacht: nachdem ich einige Zeit an Feature X gearbeitet hatte, habe ich ein paar Bugs in der Produktionsversion behoben -- ein klassischer Hotfix. Die git flow Tools sorgen dafür, daß diese Fehlerkorrekturen in develop und in den Releases auftauchen -- nur mein Feature-Zweig war weiter verbuggt. Was tun? Ich habe mich dafür entschieden, den Feature-Zweig mittels Rebase an der aktuellen develop-Version zu starten. Das war ein großer Fehler. Durch das Rebase gab es nämlich Diskrepanzen zwischen meinem lokalen Repository und der zentralen Version, die sich nicht leicht (und vor allem nur fehleranfällig) korrigieren ließen. Git flow bemerkt das auch und verweigert an viele Stellen gleich den Dienst. Ich habe es zwar hinbekommen, aber mein Commit-Graph ist ziemlich unübersichtlich geworden.

Lektion gelernt: man kann jederzeit Feature-Zweige nach develop Mergen,5 aber nicht umgekehrt. Die letzten Bugfixes sind bei einer reinen Entwicklerversion oft auch überflüssig; und wenn man sie wirklich braucht, ist wahrscheinlich Cherry-Picking die beste Methode.

Übrigens hat git eine unangenehme Eigenschaft, die mich überhaupt erst in diese missliche Lage gebracht hat: Man kann die Geschichte umschreiben (rewriting history), i.e. es gibt git-Kommandos, die nicht nur neue Vertizes zum Commit-Graphen hinzufügen, sondern bestehende Vertizes löschen oder ändern. Das widerspricht meinen Erwartungen an ein Versionskontrollsystem sehr, es liegt aber wohl im Konzept der verteilten Repositories, und ließe sich nur mit schweren Nachteilen ausschließen.

1. Branches [↩]
2. oder zumindest solche, die man veröffentlichen könnte [↩]
3. schwerere Bugs, die zwischendurch behoben werden müssen [↩]
4. Feinschliff zur nächsten Version [↩]
5. ich schrieb ja schon, daß man diese Begriffe nicht sinnvoll übersetzen kann [↩]