Mozilla Firefox-Code-Repository von Mercurial zu GitHub migriert

• Firefox hat kürzlich sein Haupt-Repository von Mercurial zu GitHub migriert
• Bug-Tracking bleibt bei Bugzilla, Code-Reviews weiterhin bei Phabricator und CI weiterhin bei Taskcluster
• Derzeit ist GitHub das zentrale Repository, während der Mercurial-Server weiterhin durch Synchronisierung von GitHub aus gepflegt wird; auch bestehende Automatisierungssysteme sollen schrittweise auf Git umgestellt werden
• Das try-Repository für CI-Tests basiert weiterhin auf Mercurial, wird aber zunehmend hinter einer Abstraktionsschicht verborgen und soll künftig auf Git umgestellt werden
• Da Git nun standardmäßig verwendet werden kann, besteht der Vorteil, dass neue Beitragende nicht mehr zusätzlich Mercurial lernen müssen, sondern nur noch Git beherrschen müssen
  • Früher musste dafür die Erweiterung git cinnabar installiert werden, jetzt reicht die Standardversion von Git aus
• Das bisherige Mercurial-mozilla-central wurde in Git in den Branch main umbenannt, und der Branch autoland bleibt auch in Git autoland
• Der PR-basierte Workflow von GitHub wurde derzeit nicht eingeführt und ist nicht Teil dieser Änderung. Die Möglichkeit bleibt für die Zukunft offen, es gibt jedoch keinen offiziellen Plan
• Mozilla kann durch den Wechsel zu GitHub den Betriebsaufwand für die eigene VCS-Infrastruktur reduzieren
• Hauptziel ist es, die Kosten und die Komplexität zu senken, die damit verbunden sind, Leistung, Stabilität und Verfügbarkeit für ein Großprojekt selbst bereitzustellen

Detaillierte Chronik und Erläuterung vom Autor von git-cinnabar, Glandium: How I (kind of) killed Mercurial at Mozilla

> Mozilla beendet mit der Umstellung des Firefox-Code-Repositorys auf GitHub die Mercurial-Ära

• Mozilla hat beschlossen, das zentrale VCS für die Firefox-Entwicklung von Mercurial auf Git umzustellen und GitHub als offizielles Repository zu nutzen
• Grundlage dieser Entscheidung war auch die langjährige Entwicklung und Verbreitung des Erweiterungswerkzeugs git-cinnabar, das Git-Nutzern einen reibungslosen Zugriff auf Mercurial-Repositories ermöglichte
• Probleme mit der Branch-Struktur von Mercurial, das Wachstum der Repository-Größe und der Aufwand für den Betrieb eigener Server wirkten zusammen, sodass sich die Schwierigkeiten beim Erhalt der eigenen Infrastruktur immer weiter summierten
• Die Wahl von GitHub ist zwar nicht unumstritten, war aber angesichts von bereits tausenden internen Mozilla-Repositories auf GitHub im Hinblick auf Beitragsfreundlichkeit und Pragmatismus kaum zu vermeiden
• git-cinnabar begann als persönliches Side-Project aus einem internen Mozilla-Bedarf heraus, dürfte aber auch während der Übergangsphase weiterhin ein wichtiges Werkzeug bleiben
  > „Ich habe das Feuer nicht gelegt, aber ich habe definitiv Öl hineingegossen.“

[GN⁺]

Hacker-News-Kommentare

• Ich arbeite bei Mozilla, bin aber weder am VCS-Tooling noch an dieser Umstellung beteiligt; ich möchte nur etwas zusätzlichen Kontext geben. Das offizielle Repository des Firefox-Codes wurde kürzlich von Mercurial auf hg.mozilla.org zu GitHub verschoben. Betroffen ist nur der Code; für das Issue-Tracking wird weiterhin Bugzilla verwendet, für Code-Review und Landings Phabricator und für CI das Taskcluster-System. Kurzfristig wird der Mercurial-Server weiterhin von GitHub aus synchronisiert, damit die Automatisierungssysteme schrittweise auf ein Git-Backend umgestellt werden können. Mercurial wird weiterhin für das „try“-Repository verwendet, also dort, wo CI für WIP-Patches läuft, verschwindet aber zunehmend hinter einer Abstraktionsschicht; auch das soll später migriert werden. Für Leute, die an das alte Repository gewöhnt sind: „mozilla-central“ wird auf den in Git üblichen Branchnamen „main“ abgebildet, „autoland“ auf den Branch „autoland“. Schon bisher konnte man grundsätzlich auch nur mit Git zu Firefox beitragen, dafür musste jedoch die Erweiterung git-cinnabar installiert werden. Die Wahl zwischen dem Erlernen von hg oder der Nutzung von Git plus Erweiterung war für neue Mitwirkende eine Einstiegshürde, denn die meisten kannten Git, aber nicht Mercurial. Darüber muss man sich jetzt nicht mehr den Kopf zerbrechen. Der Autor von git-cinnabar, glandium, hat zum Zeitpunkt der Migrationsankündigung in einem Blogpost ausführlich Kontext und Gründe erläutert. Kurzfristig ändert sich aus Sicht von Beitragenden fast nichts. Normales Git ist jetzt der Standard-Workflow, sonst hat sich kaum etwas geändert. Später könnte es Unterstützung für einen GitHub-PR-basierten Workflow geben, aber das ist nicht Teil dieser Änderung. Im Backend kann Mozilla nach Abschluss der Migration Zeit und Aufwand für den Betrieb der eigenen VCS-Infrastruktur reduzieren; die erforderliche Performance und Verfügbarkeit für ein Projekt dieser Größenordnung bereitzustellen, ist eine erhebliche Herausforderung
  • Persönlich halte ich Mozillas Entscheidung, auf eine geschlossene Plattform im Besitz von Microsoft zu wechseln, nicht für richtig
  • Da Phabricator eingestellt wurde, würde mich interessieren, ob es einen Plan für einen Ersatz gibt, etwa ob Phorge in Betracht gezogen wird
  • Danke für den zusätzlichen Kontext. Mich würde interessieren, welche größeren Skalierungsprobleme bei der selbstgehosteten Lösung aufgetreten sind
  • Ich würde gern wissen, ob auch GeckoView und Mozilla Android Components auf GitHub umziehen
  • Ich finde es schade, dass nur der Code zu GitHub umzieht, während das Issue-Tracking weiter in Bugzilla bleibt. Ein großer Vorteil von GitHub ist, dass viele Nutzer bereits ein Konto haben und mit der Plattform vertraut sind; wenn Issues aber nur in Bugzilla angenommen werden, bleibt auch das Melden von Bugs mit einer Hürde verbunden. Ich habe einmal über Bugzilla und Firefox einen Accessibility-Bug unter macOS gemeldet, und es war ziemlich umständlich, die Seite zu finden, sich zu registrieren und sich einzuarbeiten. Der Bug wurde am Ende bestätigt, aber nie behoben
• Aus Mozillas strategischer Sicht wirkt das wie eine nachvollziehbare Entscheidung. Die Einnahmen von Google sinken, und möglicherweise muss man Personal abbauen, aber wenn die Entwicklung von Firefox weitergehen soll, braucht es mehr Beteiligung aus der Community, und GitHub ist nun einmal die bekannteste Plattform für Entwickler, wodurch die Einstiegshürde sinkt. Man kann sich darüber ärgern, dass statt GitHub nicht GitLab oder etwas anderes genutzt wird, aber davon, dass Firefox weiterentwickelt wird und es am Markt eine konkurrierende Engine gibt, profitieren letztlich alle
  • Ich glaube nicht, dass Menschen, die ihre Mitarbeit aufgeben, weil sie GitHub nicht nutzen können, in den meisten Fällen besonders wertvolle Mitwirkende wären. Es mag Ausnahmen geben, aber in keinem nichttrivialen Open-Source-Projekt, an dem ich direkt beteiligt war, habe ich das gesehen. Im Gegenteil glaube ich, dass eine leicht erhöhte Einstiegshürde den positiven Effekt haben kann, minderwertige Einmal-Beiträge herauszufiltern
  • Ich habe die Kombination aus gh und Phabricator nicht verstanden und deshalb vollständig aufgegeben, mit Patches zu Firefox beizutragen. Ich verstand nicht, wie die beiden zusammenspielen, und wusste nicht, wie man Branches/PRs aktualisieren sollte, also habe ich den Versuch am Ende ganz aufgegeben
  • Meine persönliche Erfahrung mit GitLab ist, dass GitLab vor einigen Jahren sehr deutlich gemacht hat, dass großes Hosting von Open-Source-Projekten für sie keine besondere Priorität hat und FOSS nur über ihr Open-Source-Programm unterstützt werden konnte. Dieser Prozess ist kompliziert und bringt viele zusätzliche Anforderungen mit sich, die für Mozilla schwer akzeptabel wären. Um GitLab zu nutzen, müsste ein Open-Source-Projekt beispielsweise darauf verzichten, das Recht zu haben, die GitLab-FOSS-Version zu modifizieren oder zu forken, und das ist für jedes Projekt ein gravierendes Problem. Vielleicht hat ein Anwalt dort nur routinemäßig eine Klausel eingefügt, aber allein das zeigt schon, wie problematisch es ist. Deshalb fällt GitLab weg. Codeberg und andere bleiben zwar, aber wenn man die Einstiegshürde für neue Beitragende senken will, ist GitHub passend, weil dort die meisten ohnehin schon registriert sind
  • Auch wenn der Wechsel zu GitHub eine technische Änderung ist, liegt der eigentliche Kern im Umstieg von Mercurial auf Git, und ich vermute, dass soziale Überlegungen die technische Entscheidung beeinflusst haben
  • Ich denke, wer die Einstiegshürde nicht überwinden kann, sollte nicht einmal Bugs melden und erst recht keinen Code ändern
• Es ist gut, dass damit ein wesentlicher technischer Altlastenpunkt für Beiträge zu Firefox beseitigt wurde. Als ich es vor einigen Jahren versucht habe, dauerte das Klonen des Mercurial-Repositories mehrere Stunden, und ohne offizielle Git-Unterstützung musste man inoffizielle Git-Unterstützung verwenden, um vernünftig arbeiten zu können. Die Dokumentation war damals zudem chaotisch und führte dazu, dass man unnötigerweise alles neu baute
• Ich frage mich, warum man statt der bestehenden mozilla-Org die mozilla-firefox-Org gewählt hat
  • Wahrscheinlich wegen anderer Zugriffsregeln oder um sie von der bestehenden Org zu trennen, damit Automatisierung nicht versehentlich auch andere Bereiche beeinflusst
  • Wirklich eine sehr gute Frage
• Ich frage mich, was die Quelle für „Firefox Moves to GitHub“ ist. Es könnte auch einfach nur ein Mirror sein. Linux hat ebenfalls einen Mirror auf GitHub. (Später bearbeitet: Quelle ergänzt)
  • Das dachte ich auch. Tatsächlich ist der auf GitHub eingerichtete Workflow nur dazu da, PRs mit einer Standardantwort zu schließen
• Firefox Mobile (Fenix) nutzte früher GitHub, wurde dann aber vor einiger Zeit in Mozillas Mercurial-Repository mozilla-central migriert; jetzt sind sowohl die Desktop- als auch die Mobile-Version wieder auf GitHub, während die Issues in Bugzilla bleiben. Man kann also die gute Suche von GitHub, das Source-Browsing und die Vertrautheit mit Git nutzen. Als früherer Beitragender zu Firefox und Thunderbird habe ich ohnehin viel häufiger lokal gesucht als auf der mozilla-central-Seite. Während der Entwicklung sucht man im IDE, aber eine einfache Suche auf der Website ist für neue Beitragende auf jeden Fall willkommen
  • Umgekehrt finde ich Searchfox das beste Code-Navigationstool, das ich je benutzt habe. Es bietet funktionsübergreifende Navigation über verschiedene Sprachen hinweg, dauerhaft verfügbare Blame-Informationen und vieles mehr und ist viel schneller und schlanker als GitHub. Es wäre schön, wenn mehr Projekte solche Tools nutzen könnten, und es wäre schade, wenn es verschwinden würde
  • Ich habe den Eindruck, dass die Qualität des Source-Browsings auf GitHub in letzter Zeit massiv nachgelassen hat. Asynchrones Laden (JavaScript erforderlich), Ausfälle bei instabiler Netzwerkverbindung, kaputte Suche innerhalb der Seite. Auch die jüngste Überarbeitung von Issues/PRs halte ich für einen Rückschritt, und mit uBlock Origin ist die PR-Suche nicht nutzbar
• Ich halte das für eine gute Änderung, frage mich aber, warum eine neue Org geschaffen wurde statt die bestehende github.com/mozilla-Org zu nutzen
  • Die genauen Gründe kenne ich nicht, aber in einigen Bereichen muss man offenbar auf Org-Ebene trennen; zum Beispiel lässt sich SSO nur für die gesamte Org aktivieren, sodass das Firefox-Repo ein völlig anderes Authentifizierungs- und Nutzer-Setup haben kann als die Haupt-Repos von Mozilla
  • Mozilla hat mehrere Orgs
  • Vermutlich wegen Conway’s Law
  • GitHub kennt nur Org- oder Repo-Ebene, nichts darüber. Viele Einstellungen (SSO, Zugriffsrechte, gemeinsame Konfiguration usw.) gelten pro Org, daher ist das Anlegen einer neuen Org oft die sauberste Lösung, auch wenn es unpraktisch ist (in GitLab könnte man innerhalb einer Instanz oder Org Namensräume wie Firefox und andere Dinge anlegen)
• Es fühlt sich seltsam an, dass eine Organisation wie Mozilla externes Hosting wie GitHub nutzt. Bei kleinen Ein-Personen-Projekten verstehe ich das, aber von Beitragenden ein Konto bei einem externen Dienst zu verlangen, ist nicht besonders freundlich
  • Für ein Open-Source-Projekt halte ich das für positiv, weil es Sichtbarkeit schafft und eine Umgebung bietet, die für alle offen und leicht zugänglich ist
• Soweit ich mich erinnere, war der Branch „master“ gleichbedeutend mit mozilla-central. Jetzt gibt es „main“ und „autoland“; ich frage mich, was das ist und welcher Branch dem früheren mozilla-central entspricht
  • Ich bin kein Firefox-Entwickler, aber „main“ ist wohl dasselbe wie mozilla-central, und „autoland“ ist der Branch, den es schon früher daneben gab und auf dem Commits zuerst landen
• Ich hoffe, dass Bugzilla erhalten bleibt, selbst wenn es nur noch schreibgeschützt wäre. Das Web ist eine Plattform, die ad hoc über Jahre gewachsen ist, und viele historische Begründungen stehen nur in Bugzilla. Auch warum verschwundene Websites oder Browser ein bestimmtes Verhalten hatten, lässt sich oft nur dort nachvollziehen
  • Bugzilla ist weiterhin der Bug-Tracker für Firefox. Es gibt keine Pläne, das zu ändern. (GitHub Issues werden nicht verwendet)
  • Bugzilla war großartig und seiner Zeit voraus. Ich glaube nicht, dass es selbst heute einen ähnlich guten selbstgehosteten Bug-Tracker gibt