Seit mehr als einem Jahrzehnt ist KOMA-Script als Projekt bei BerliOS beheimatet. Entstanden ist die Partnerschaft, als ich für KOMA-Script 3 eine Heimat für ein öffentliches Source-Repository gesucht habe. Damals gab es mit LPPL als Lizenz bei diversen der bekannteren, kostenlosen OpenSource Hoster noch einige Probleme. BerliOS erkannte aber bereits damals LPPL als freie Lizenz an. Außerdem fand ich den Gedanken, meine Quellen nicht jedes Mal über sämtliche Kontinente zu schicken, vernünftig. Beides zusammen war der Hauptgrund, warum ich mich damals zu einem Projekt koma-script3 auf BerliOS entschieden habe.
Viele Jahre klappte das ganze überwiegend gut. In den Jahren 2010 und 2011 häuften sich die Probleme mit dem Zugang zum Download-Server. Der Developer-Server lief allerdings weiterhin stabil. Ende 2012 gab es dann die Hiobsbotschaft, dass Fraunhofer die Finanzierung des Projekts beenden werde und deshalb das ganze eingestellt würde. Erfreulicher Weise gelang es kurzfristig einen Verein ins Leben zu rufen, der den Weiterbetrieb sicherstellte. Infolge einer Zusammenarbeit mit SourceForge war dann auch die Download-Server kein Problem mehr.
Doch nun wurden sämtliche Entwickler informiert, dass der Developer-Service endgültig eingestellt wird. Gestern ging unter www.berlios.de ein neuer Service online, der nichts mehr mit dem bisherigen zu tun hat. developer.berlios.de wird am 30. April endgültig die Pforten schließen. Ob und wohin ich dann mit dem KOMA-Script-Quellen umziehen werde, ist noch nicht raus. Was leider auf jeden Fall verloren gehen wird, ist die Release-Datenbank, aus der man sich bisher nahezu mühelos sämtliche Versionen von KOMA-Script seit 2006 besorgen konnte. Da in den nächsten Monaten auch koma-script.de den Server wechseln wird, besteht eine kleine Chance, dass ich für zukünftige Versionen etwas ähnliches hier aufziehen werde. Ob die Spiegelung der Dateien (ohne die Release-Infos) auf SourceForge erhalten bleiben wird, kann ich noch nicht sagen. Aus der Mail, die ich erhalten habe, werde ich auch nicht ganz schlau, ob die Projekte automatisch zu SourceForge migriert werden oder wir das ggf. selbst vornehmen müssen. Die Informationen von BerliOS waren leider noch nie sehr gut.
Für diejenigen, die gerne das Source-Repository genutzt haben, wird es aber wohl eine Umstellung und möglicherweise für längere Zeit auch einen Wegfall dieser Möglichkeit geben. Das ist schon deshalb bedauerlich, weil es im Betatest und in der Verbesserung der Anleitung höchst nützlich war.
Kommentare
Nacht und Nebelaktion
Da es unmöglich war, mit einem sinnvollen zeitlichen Aufwand, alle notwendigen Information zur automatischen Migration nach SourceForge von den Verantwortlichen bei BerliOS zu bekommen, habe ich heute Vormittag in einer Nach-und-Nebel-Aktion die Quellen von KOMA-Script selbst nach SourceForge migriert.
Für diejenigen unter Euch, die mit dem Repository arbeiten, bedeutet das, dass sie ebenfalls zum SourceForge Repository von KOMA-Script wechseln müssen.
Mich selbst wirft das in einigen wenigen Punkten etwas zurück, weil ich beispielsweise die weitgehend automatisierte Erstellung neuer Pakete und Releases noch auf dieses Repository umstellen muss. Allerdings war mir die Gefahr, dass der Umzug dann schief geht, wenn ich nur noch Stunden dafür habe, einfach zu groß.
Und nein, ich werde nicht darüber diskutieren, ob ich bei der Gelegenheit nicht besser auch gleich die Art des Repositories geändert hätte und einen ganz anderen Hoster verwendet hätte etc. Ich habe für derlei Dinge eigentlich rein gar keine Zeit!
Es geht auch noch härter
Wie ich gerade feststellen durfte, hat Sarovar.org, der langjährige Hoster von splitindex, am 26. Dezember ebenfalls die Pforten geschlossen. Allerdings habe ich von dem keine Vorwarnung bekommen. Die gab es wohl im Sarovar-Forum, das ich nie verfolgt habe. Bemerkt habe ich das erst jetzt, als ich eine neue Version einchecken wollte. Damit geht die gesamte Historie des Pakets verloren. Nun, es gibt sicher schlimmeres, aber ein wenig ärgerlich ist es doch. Außerdem muss ich nun auch noch für dieses Paket irgendwo ein neues Projekt aufsetzen …
Geht doch
Wie ich entdeckt habe, gibt es zwar keinen direkten Zugriff auf die alten Repositories mehr, aber man kann indirekt über das Web-Frontend noch darauf zugreifen. Da das noch ein altes CVS-Repository war, gibt es keine globale Revisionen, sondern jede Datei hat ihre eigene Historie und ihre eigene von den anderen Dateien unabhängige Revisionsnummern. Also musste ich nicht nur ein Skript schreiben, das mir über das Web-Frontend die Dateien holt, um die Historie (allerdings ohne jeweiliges Datum) zu übertragen, musste ich auch noch die Dateien in der jeweiligen Revision in der richtigen Reihenfolge holen, um sie in ein neues subversion-Repository zu schreiben. Dazu mussten dann die Änderungen, die ich in letzter Zeit über ein neues, lokales Repository vorgenommen hatte, ebenfalls übertragen werden. Das ging aber Dank globaler Revisionsnummern dann schnell. Jetzt habe ich also ein neues (nicht öffentliches) Repository mit der gesamten Historie.
Nein, das gibt keine neue Release. Die gab es ja bereits vor ein paar Tagen. Das war nur für mich.