Die Emacs-hafteste Bzr-Saga
(thanosapollo.org)- 2008 prüfte Emacs nach CVS Git und Bazaar als Nachfolger, und in Benchmarks war Git deutlich schneller
- Richard Stallman legte die Wahl auf Bazaar fest, weil es ein GNU-Paket war; technische Diskussionen konnten die Entscheidung nicht ändern
- Während GitHub von 2008 bis 2012 wuchs, mussten Emacs-Mitwirkende Bazaar lernen, und Canonical entließ 2012 das Entwicklungsteam
- 2013 lösten die stagnierende Bazaar-Wartung und ein Bug im ELPA-Branch eine erneute Debatte aus; ELPA wechselte schließlich zu Git
- 2014 wechselte Emacs nach der Migrationsarbeit von Eric S. Raymond zu Git, doch direkt danach zeigte sich, dass zentrale Mitwirkende Git erst lernen mussten
2008: Git war schneller, aber Bazaar wurde gewählt
- Im März 2008 wollte Emacs von CVS auf ein moderneres Versionsverwaltungstool umsteigen, und die Kandidaten wurden auf Git und Bazaar eingegrenzt
- Git war ein von Linus Torvalds für den Linux-Kernel entwickeltes Tool
- Bazaar war ein von Canonical gepflegtes GNU-Projekt
- Auf emacs-devel lief eine Diskussion mit 236 Nachrichten, und mehrere Entwickler benchmarkten die beiden Werkzeuge
- Andreas Schwab bewertete
bzr log, dessen Start mehr als eine Minute dauerte, als „so langsam, dass es völlig unbenutzbar ist“ - David Kastrup meinte, während
git logfast sofort laufe, wirke Bazaar so, als müsste es schneller sein, weil es Informationen über Datei-Kopien, -Verschiebungen und -Umbenennungen explizit erhalte
- Andreas Schwab bewertete
- Auch in den konkreten Zahlen war die Git-Überlegenheit klar erkennbar
git log | head -1brauchte 0,012 Sekunden, während Bazaar für dieselbe Aufgabe 21,5 Sekunden benötigte- Ein Commit mit einer Änderung an nur einer Datei dauerte bei Git 0,08 Sekunden, bei Bazaar 17 Sekunden
- Der damalige leitende Maintainer Stefan Monnier sagte, entscheidend sei nicht, ob Bazaar schneller oder langsamer als Git sei, sondern dass es für einen Umstieg von Emacs „schnell genug“ sein müsse; insbesondere dürfe
bzr diffnicht mehr als ein paar Sekunden dauern - Der Canonical-Bazaar-Entwickler Jonathan Lange schlug für den ersten Checkout ein Verfahren vor, das
wget,tar,bzr init-repo,bzr branchundbzr pull --rememberkombiniert- Dieses Verfahren war lang und manuell genug, um stark mit
git clonezu kontrastieren
- Dieses Verfahren war lang und manuell genug, um stark mit
Die Entscheidung, ein GNU-Tool verwenden zu müssen
- Jemand fragte die Emacs-Maintainer und Entscheidungsträger, welche weiteren Informationen nötig wären, um sie davon zu überzeugen, dass bzr zum jetzigen Zeitpunkt nicht das richtige Tool sei
- Richard Stallman antwortete, diese Wahl sei keine Entscheidung für den aktuellen Moment, sondern eine langfristige Entscheidung, und es sei besser, ein paar Monate zu warten, bis die Bazaar-Entwickler Verbesserungen umsetzen, als eine vorläufige Entscheidung zu treffen, die sich nur schwer rückgängig machen lasse
- In einer separaten Nachricht stellte Stallman klar: „Diese Frage ist abgeschlossen und entschieden. Wir werden GNU Bzr verwenden. Weil es ein GNU-Paket ist.“
- Auf den Einwand, technische Argumente würden durch eine politische Entscheidung überlagert, antwortete Stallman mit Verweis auf die Regel, dass GNU-Pakete einander unterstützen, weil dies das GNU-System insgesamt besser funktionieren lasse
- Auf die Frage, ob man Git nicht zum Teil des GNU-Systems machen könne, sagte er, Git könne zwar in das GNU-System aufgenommen werden, halte es aber für unwahrscheinlich, dass die Git-Entwickler Git zu einem GNU-Paket machen wollten
- Weder die Benchmarks von 2008 noch die 236 Nachrichten noch das Ausweichverfahren eines Canonical-Mitarbeiters änderten das Ergebnis: Emacs entschied sich für Bazaar, weil es ein GNU-Paket war
2008–2012: Die Verbreitung von Git und die Last von Bazaar
- Während GitHub 2008 startete und schnell wuchs, mussten Emacs-Mitwirkende Bazaar lernen, um Patches einzureichen, obwohl sie es anderswo nicht verwendeten
- Auf emacs-devel tauchten wiederholt Threads zu Bazaar-Problemen auf
- „Help me unstick my bzr, please“
- „Can NOT bzr the emacs repos (may be bzr has a memory leak)“
- 2012 entließ Canonical das Bazaar-Entwicklungsteam
- Danach wurde der Wartungszustand von Bazaar zu einer noch größeren Belastung im Emacs-Entwicklungsprozess
2013: Stagnierende Wartung und neue Git-Debatte
- Im März 2013, ein Jahr nachdem die Bazaar-Entwicklung faktisch zum Stillstand gekommen war, fragte John Wiegley erneut, ob Emacs zu Git wechseln könne
- Die Bazaar-Entwicklung war faktisch eingefroren
- Wichtige Bugs, die die Emacs-Entwicklung beeinflussten, etwa im ELPA-Repository, standen seit Jahren ungelöst im Bugtracker
- Auch diese Diskussion umfasste etwa 200 Nachrichten
- Stallmans erste Reaktion war, dass ein Bazaar-Maintainer einige Bugs behebe und er selbst erst am Vortag um einen Fix für den ELPA-Branch-Bug gebeten habe; er wolle daher eine angemessene Frist einräumen
- Dmitry Gutov fragte, ob das nicht zu spät sei, da es sich um einen 1,5 Jahre alten Bug handle
- Stallman sagte, er versuche zu beurteilen, ob Bazaar noch effektiv gewartet wird, und gab an, er wolle dabei gern ein „Ja“ als Antwort erhalten
- Joakim Verona sagte, die Bazaar-Community sei sehr hilfsbereit, doch es gebe viele bekannte Bugs und Patches, von denen einige von Emacs-Entwicklern stammten und trotzdem über Jahre nicht upstream übernommen worden seien
- Stallman antwortete, er habe keine Zeit, die Bazaar-Mailingliste zu lesen, und die einzige Entwicklungs-Mailingliste, die er lese, sei emacs-devel
- Auf die Frage, ob Bazaar-Nutzer bei der Einschätzung, ob Bazaar ausreichend gewartet werde, ein Mitspracherecht haben sollten, sagte er, relevante Informationen würden zwar berücksichtigt, den Nutzern aber ein „Mitspracherecht“ zu geben, sei unangemessen
Karl Fogels Kritik und das Delegationsproblem
- Producing Open Source Software, dessen Autor Karl Fogel ist und der zu den frühen Subversion-Entwicklern gehörte, kritisierte Stallmans Vorgehensweise bei der Beurteilung und das Fehlen von Delegation
- Fogel meinte, wenn Stallman keine Zeit habe, den Zustand der Bazaar-Entwicklung genau zu prüfen, könne er auch schwer kompetent beurteilen, ob Bazaar weiterhin eine gute Wahl für Emacs sei
- Er argumentierte, dass Stallman, wenn ihm Zeit und geistige Kapazität für diese Bewertung fehlten, an die Emacs-Maintainer delegieren sollte
- Laut Fogel könne die Frage an eine einzelne Person zu einem einzelnen Bug kein brauchbarer Stellvertreter für die Gesundheit eines Projekts sein, zumal andere im Thread bereits gründlichere Recherchen angestellt hätten
- Stallman antwortete, es gehe „um mehr als Emacs“
- Der Kernpunkt war, welches Signal es an andere GNU-Pakete sende, wenn ein repräsentatives GNU-Projekt ein GNU-Tool aufgebe
- Fogel forderte erneut, Stallman solle entweder genügend Zeit investieren, um den Wartungszustand von Bazaar vertrauenswürdig beurteilen zu können, oder an jemanden delegieren, der das könne
- Stallman antwortete nur, er habe bereits einen Plan und arbeite ihn ab, nannte aber weder Details noch Zeitplan und bot auch keine Delegation an
ELPA wechselte zuerst zu Git
- In der Debatte von 2013 sagte Stefan Monnier, es sei ihm im Grunde egal, ob man bei Bazaar bleibe oder zu Git, Monotone, Darcs, Mercurial, OpenCM oder Fossil wechsle
- Für Stefan war kurzfristig wichtig, den ELPA-Branch aus Bazaar herauszubekommen
- Der Grund war, dass Bazaar den ELPA-Branch nicht korrekt verarbeiten konnte
- Leo Liu wies darauf hin, dass die meisten GNU-Projekte Bazaar nicht verwendeten
- Er meinte, das Beheben von Bazaar-Bugs könne für Bazaar nützlich sein, für GNU insgesamt aber einen Verlust bedeuten
- Die Logik dahinter war, dass es Freiwillige von der Mitarbeit an GNU-Projekten abschrecken könne, wenn 20 % ihrer Freizeit dafür draufgingen, mit Bazaar zu kämpfen
- Später im selben Jahr migrierte Stefan Monnier den in Bazaar kaputten ELPA-Branch zu Git
- Im ELPA-Branch gab es einen Bug, der beim Checkout zu Konflikten führte, und niemand war mehr da, um ihn zu beheben
- Stefan sagte, ihm gefalle ein Zwei-Tool-System mit Git für ELPA und Bzr für trunk zwar nicht, er sehe aber keinen anderen Ausweg
- Er machte klar, dass diese Änderung nicht zu einer Debatte über die Vor- und Nachteile von Git und Bazaar oder über eine Git-Migration von
trunkausgeweitet werden solle
- Mit dem Wechsel von ELPA zu Git entstand die Grundlage für die nächste Debatte: Wenn Git für ELPA gut genug ist, warum dann nicht auch für trunk?
2014: Die Migrationsarbeit von Eric S. Raymond und der tatsächliche Wechsel
- Im August 2014 hatte Eric S. Raymond die Migrationsskripte für das Emacs-Repository bereits vorbereitet
- Er sagte, die gesamte schwierige Arbeit sei erledigt, und es brauche nur noch ungefähr acht Stunden Vorankündigung, bevor man den Knopf drücke
- Die tatsächliche Migration erfolgte im November 2014
- Am 13. November verschickte ESR die Nachricht mit sechs Wörtern: „Commits are open. Have at it.“
- Dieser Wechsel wurde von einigen als heroic beschrieben
- Nach 236 Nachrichten im Jahr 2008, 200 Nachrichten im Jahr 2013, Stefans Wartungsarbeit, wiederkehrenden Bazaar-Problemen und einem toten Versionsverwaltungssystem war Emacs schließlich bei Git angekommen
Nach der Migration: Auch zentrale Mitwirkende mussten Git erst lernen
- In den Tagen direkt nach dem Wechsel zeigte sich, dass viele zentrale Mitwirkende Git noch nie benutzt hatten
- Auf emacs-devel folgten mehrere Threads mit Fragen zur Git-Nutzung
- „This Is The Git Help Mailing List“
- „git pull fails with merge conflicts. How can this possibly happen?”
- „A simple git workflow for the rest of us”
- „need help adjusting workflow to git”
- „Good book on Git”
- „Obscure error/warning/information message from git pull” lief auf 124 Nachrichten hinaus
- Dass Menschen, die seit Langem an einem wichtigen Texteditor arbeiteten, grundlegende Git-Fragen stellen mussten, lag auch daran, dass Emacs so lange bei Bazaar geblieben war, während die übrige Welt zu Git wechselte
1 Kommentare
Lobste.rs-Kommentare
Wenn man an einem Projekt arbeitet, das von rms geleitet wird, dreht man vermutlich wirklich durch
Wirklich eine beeindruckende Geschichte. Vor langer Zeit habe ich an irgendeiner Universität einen Vortrag gesehen, in dem Mark Shuttleworth das ursprüngliche Bazaar erklärte, und die Idee eines verteilten Versionsverwaltungssystems fand ich damals unglaublich spannend
Danach kam die Neufassung von bzr heraus, und ich war völlig begeistert. Es erschien mir viel sinnvoller als Git, und ich habe mehrere Jahre in das Projekt gesteckt, auf der Mailingliste mitdiskutiert, Plugins gebaut und sogar versucht, den Algorithmus zum Vergleichen von Code-Unterschieden in C neu zu schreiben, um ihn schneller zu machen
Am Ende wurde klar, dass Git gewonnen hatte, aber es hat ziemlich lange gedauert, bis ich das akzeptiert habe
Laut dieser Zusammenfassung soll Richard Stallman dem Emacs-Projekt bis 2013 den Umstieg auf Git verboten haben. Danach heißt es, Emacs sei Ende 2013 und Ende 2014 in zwei Schritten auf Git umgezogen, aber nach Anfang 2013 wird Stallman nicht mehr erwähnt
Er hatte Bazaar jahrelang unterstützt, hat er danach in den Mailinglisten-Threads wirklich keine Beiträge mehr dagegen geschrieben? Oder hatte er in der Zwischenzeit die Kontrolle über das Emacs-Projekt verloren?
In dem im Artikel verlinkten Thread von 2014 habe ich keine E-Mail mit seinem Namen gesehen, aber vielleicht gab es andere, nicht verlinkte Threads. Ich dachte erst, das sei ungefähr die Zeit gewesen, als Stallman wegen einer Kontroverse irgendwo zurücktrat, aber das war nicht so, ich hatte da etwas anderes im Kopf. Laut Wikipedia verließ Stallman 2019 die Free Software Foundation und hatte das GNU Project auch nicht verlassen
Ich weiß nicht genau, wodurch ein Projekt offiziell zu einem GNU-Projekt wird. Liegt es an der Lizenz? Git und Linux sind beide nur GPLv2, Bazaar ist GPLv2+. Liegt es an der Abtretung des Urheberrechts? An Hosting für Repository, Issue-Tracker, Mailinglisten und so weiter? An einem Namen mit dem Präfix „GNU“, das wie eine Art Unterstützung wirkt?
Es scheint auf jeden Fall irgendeine wichtige Unterscheidung zu geben, aber ich weiß nicht, worin sie besteht oder warum sie wichtig ist
Und dann gibt es noch den wiederkehrenden Off-by-one-Fehler:
Um 2014 herum wollte ich irgendetwas mit mysql machen, habe aber den ganzen Tag erfolglos versucht, nur das Repository zu klonen und einen Release-Branch auszuchecken, und dann aufgegeben. Das ist mir jetzt deutlich weniger peinlich
Davor hatte ich jahrelang CVS, Subversion und Mercurial benutzt, deshalb dachte ich, es liege am Netzwerk oder an meinem Rechner. Vor diesem Artikel wusste ich nicht, dass die tatsächlichen Benchmarks von bzr so katastrophal waren und dass Canonical das bzr-Team bereits entlassen hatte, obwohl sie bzr so intensiv nutzten
Einige Jahre später bin ich wegen einer anderen Aufgabe bei mysql gelandet, da war es schon auf Git umgestellt, und weil ich nicht schon vor dem eigentlichen Start blockiert war, konnte ich interessante Arbeit erledigen
Toller Artikel. Ich wollte schon immer sehen, wie sich solche Mailinglisten-Dramen entwickeln, hatte aber nie den Mut, selbst hineinzuspringen. Der Aufbau der Geschichte und die ausgewählten Zitate sind wirklich gut
Die verworrene Geschichte ist unterhaltsam aufbereitet. Ich frage mich allerdings, ob der Titel nicht eher „The Most Bzr Emacs Saga“ statt „The Most Emacs Bzr Saga“ heißen sollte
„Emacs“ als Adjektiv zu verwenden ist zwar nicht völlig ausgeschlossen, wirkt aber trotzdem etwas seltsam
Bazaar war das erste Versionsverwaltungssystem, das ich je benutzt habe. Damals stieg ich über Ubuntu gerade erst in Linux ein, und Canonical nutzte Launchpad, um Quellcode zu hosten
Davor hatte ich meinen Code nirgendwo hochgeladen, und Launchpad zusammen mit Bazaar wirkte ziemlich cool. Natürlich waren meine Projekte so klein, dass ich überhaupt keine Performance-Probleme bemerkt habe