Ein Jahr nach dem Umzug von Guix zu Codeberg

 (guix.gnu.org)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Guix verlegte 2025 seine seit über 10 Jahren auf Savannah und dem E-Mail-basierten Debbugs beruhende Zusammenarbeit zu Codeberg und veränderte damit den Einstiegspunkt für Beiträge in einem Projekt, an dem jährlich mehr als 400 Personen mitwirken
  • Der Wechsel war der erste Praxiseinsatz des im Dezember 2024 eingeführten Verfahrens Guix Consensus Document; GCD 002 trat nach zweimonatiger Diskussion Anfang Mai 2025 in Kraft
  • Der bisherige E-Mail-Workflow war für Erfahrene dank Werkzeugen wie Emacs, mumi und qa.guix.gnu.org effizient, wurde in einer Umfrage mit 900 Antworten von Mitwirkenden aber häufig als Hürde genannt
  • Nach dem Wechsel zu Codeberg stiegen die Zahl der Autorinnen und Autoren sowie der neuen Autorinnen und Autoren, doch abgesehen von einem vorübergehenden Peak im Juni 2025 lässt sich ein klarer Codeberg-Effekt nur schwer feststellen
  • Jeden Monat werden mehr als 500 Pull Requests eröffnet und der Backlog wächst, sodass das Schließen der CI-Lücke, das Signaturerfordernis und die Review-Last die nächsten praktischen Aufgaben für Guix bleiben

Von E-Mail-basierter Zusammenarbeit zu Codeberg

  • Guix migrierte 2025 Source-Code-Hosting, Issue-Tracking und Pull Requests zu Codeberg
    • Zuvor wurde der Code über mehr als zehn Jahre auf Savannah gehostet
    • Bugreports und Patches wurden per E-Mail abgewickelt und über eine Debbugs-Instanz nachverfolgt
    • Für ein Projekt, zu dem jedes Jahr mehr als 400 Personen Code beitragen, war der Wechsel selbst eine große Veränderung
  • Die bisherigen Kernbeitragenden waren an den E-Mail-Workflow gewöhnt und arbeiteten mit dem Debbugs-Paket für Emacs oder fortgeschrittenen E-Mail-Clients effizient
    • Debbugs stützt sich auf einige hundert Zeilen Perl-Code sowie E-Mail-Standards und föderierte Strukturen, während Web-Forges wie Forgejo größere Systeme mit vielen Go-Abhängigkeiten sind
  • Rund um den E-Mail-Fluss hatten sich bereits Hilfswerkzeuge etabliert
    • mumi bietet ein Web-Interface für Debbugs
    • Der Quality Assurance service wendet E-Mail-Patch-Serien automatisch auf Git-Branches an und baut auf diesen Branches die Pakete
  • Auf die erste Umfrage unter Nutzerinnen, Nutzern und Mitwirkenden, die im Januar 2025 veröffentlicht wurde, antworteten mehr als 900 Personen; Mitwirkende nannten den E-Mail-Workflow häufig als Hürde für Beiträge

Konsensbasierte Entscheidung mit GCD 002

  • Bei Guix gibt es keinen „benevolent dictator“, der Entscheidungen trifft; daher wurde im Dezember 2024 der Prozess Guix Consensus Document process eingeführt
  • Das GCD-Verfahren zielt eher auf Konsensbildung als auf eine einfache Abstimmung
    • Die Person, die den Vorschlag verfasst, muss ihn gemeinsam mit den Beteiligten anpassen
    • Beteiligte sollen statt bloßer Ablehnung ihre Bedürfnisse und konkrete Änderungen vorschlagen, die diese berücksichtigen
    • Im finalen Entwurf wird die Position mit support, accept oder disapprove angegeben
  • GCD 002 wurde im Februar 2025 als Vorschlag für den Umzug zu Codeberg eingereicht
    • Die Diskussion lief über den verfahrensmäßig maximalen Zeitraum von zwei Monaten
    • Zwei Drittel des Guix-Teams beteiligten sich an der Beratung
    • 72 % der Teilnehmenden wählten support, die übrigen 28 % accept
    • disapprove gab es nicht, und der Vorschlag trat Anfang Mai 2025 in Kraft
  • Einige langjährige Mitwirkende empfanden einen scheinbar Web-zentrierten Workflow als weniger effizient als E-Mail und sahen den Verzicht auf Teile der E-Mail-basierten Infrastruktur ungern
  • Die Möglichkeit, mehr Berührungspunkte mit der breiteren Community zu schaffen und die Developer Experience zu verbessern, trug den Wechsel mit
  • Dass eine freie Software-Forge und eine von der Non-Profit-Organisation Codeberg e.V. betriebene Forge bevorzugt wurde, führte nicht zu größeren Kontroversen und passte zu der Ausrichtung von Guix

Schrittweiser Übergang und eine größere als erwartete CI-Lücke

  • Der Wechsel zu Codeberg erfolgte wie im GCD-Konsens vorgesehen schrittweise
    • Das Haupt-Repository wurde am 25. Mai 2025 migriert
    • Das bisherige Repository bleibt weiterhin als Mirror bestehen
    • Der bisherige Issue- und Patch-Tracker bleibt bis zum 1. Januar 2026 erhalten
    • Danach sind Codeberg-Issues und Pull Requests die einzig unterstützten Mechanismen
    • Frühere Bugreports und Patches bleiben online zugänglich
  • Dank des während der Konsensdiskussion erarbeiteten Plans gab es beim Umstieg nur wenige größere Probleme oder unerwartete Situationen
  • Die Servicequalität der Mitarbeitenden und Freiwilligen von Codeberg e.V. war gut; gelegentliche Ausfälle waren meist kurz und klar angekündigt
  • Für Mitwirkende, die Workflows außerhalb des Browsers bevorzugen, halfen verbesserte Emacs-Schnittstellen
    • fj.el und Emacs-Forgejo wurden weiterentwickelt
    • Auch die Möglichkeit, mit dem AGit workflow Pull Requests zu erstellen, verringerte den Anpassungsaufwand
  • Ein nicht ausreichend vorhergesehenes Problem war die kontinuierliche Integration für Pull Requests
    • Die Funktion von qa.guix.gnu.org, E-Mail-Patches zu bauen, wurde nicht nach Codeberg portiert
    • Mehrere Monate lang mussten Reviewer selbst prüfen, ob Pull Requests Probleme verursachen, was nicht nachhaltig war
  • Im September 2025 wurde eine Cuirass-Instanz auf pulls.ci.guix.gnu.org aufgebaut und begann, Pull Requests zu bauen
    • Anfangs galt sie wegen stärkerer Einschränkungen gegenüber qa.guix.gnu.org als Behelfslösung
    • Derzeit werden Pakete für eine einzelne Architektur gebaut
    • Neue Beitragende können die Erfolgs- und Fehlerergebnisse, die guix-cuirass-bot in Pull Requests hinterlässt, direkt sehen

Mehr Beitragsfluss, aber auch größerer Backlog

  • Betrachtet man die Zahl der Commits auf den Main-Branch von Mai 2024 bis Mai 2026, blieb das Commit-Tempo von Guix konstant zwischen „hoch“ und „sehr hoch“
  • Allein am Commit-Tempo lassen sich Veränderungen kaum erkennen; nützlichere Kennzahlen sind die monatliche Zahl der Commit-Autorinnen und -Autoren, der Committer sowie der neuen Commit-Autorinnen und -Autoren
  • Die monatliche Zahl der Autorinnen und Autoren sowie der neuen Autorinnen und Autoren steigt weiter an
    • Unmittelbar nach dem Wechsel zu Codeberg gab es im Juni 2025 einen Peak sowohl bei den Autorinnen und Autoren als auch bei den neuen Autorinnen und Autoren
    • Das Wachstum in den übrigen Zeiträumen ist in den Abschnitten 2025–2026 und 2024–2025 ähnlich
    • Guix zieht weiterhin neue Mitwirkende an, doch ein klarer Codeberg-Effekt war nicht groß
  • Die monatliche Zahl der Committer stieg flacher als die Zahl der Autorinnen und Autoren, was darauf hindeuten könnte, dass Committer mehr Beiträge verarbeiten
  • Pull-Request-Daten wurden über die Forgejo API von Codeberg erfasst
  • Jeden Monat werden mehr als 500 Pull Requests eröffnet und die Merge-Geschwindigkeit ist hoch, liegt aber leicht unter dem Zufluss, sodass der Backlog weiter wächst
    • Derzeit sind rund 639 von insgesamt 6.459 Pull Requests offen, also etwa 10 %
    • Als Vergleich wurden bei Nixpkgs rund 12k offene Pull Requests von insgesamt 473k genannt, also etwa 2,5 %
    • Der Backlog bei Guix könnte auf übermäßige Reibung oder unzureichendes CI-Feedback zurückzuführen sein
  • Bei Guix muss jeder Commit die Signatur eines autorisierten Committers erhalten
    • Anders als in vielen Projekten einschließlich Nixpkgs reicht es nicht, einfach auf den Button Merge zu klicken
    • Die Person, die merged, trägt die Verantwortung dafür, die Änderung anzuwenden und zu signieren
    • Guix entscheidet sich zwischen Entwicklerkomfort und Nutzersicherheit für Sicherheit in der Software-Lieferkette
    • Ob sich diese Kosten senken lassen, muss sich noch zeigen

Zusammenarbeit auf Codeberg sichtbarer

  • Nach dem Umzug zu Codeberg wurde die Projektaktivität sichtbarer
  • CI-Ergebnisse erscheinen direkt in Pull Requests, sodass Beitragende sie sofort prüfen können
  • Die Guix-Teams werden als Codeberg-Teams umgesetzt
    • Die Team-Bereiche sind in der Datei CODEOWNERS festgelegt
    • Zuständige Personen für den jeweiligen Bereich werden automatisch aufgerufen
    • Ein Bot vergibt Labels wie team-python, damit sich Issues und Pull Requests nach Labels filtern lassen
  • Ein Problem, bei dem Teams bei entsprechend gelabelten Issues keine Benachrichtigung erhalten, bleibt ein Ärgernis
  • Funktionen wie Querverweise zwischen Issues und Pull Requests sowie Milestones scheinen der Zusammenarbeit ebenfalls zu helfen

Offene Infrastrukturaufgaben und die Beziehung zu Codeberg

  • Die Guix-Infrastruktur braucht weitere Unterstützung
    • Die Build-Performance von pulls.ci.guix.gnu.org muss verbessert werden
    • Auch Builds für andere Architekturen als x86 wären wünschenswert
    • Cuirass hat mehrere Einschränkungen, von denen einige in der geplanten 1.4.x-Serie behoben werden
    • pulls.ci.guix.gnu.org ist weiterhin stark paketzentriert; wenn passend, wäre auch die Ausführung von Systemtests wünschenswert
  • Auch im Workflow für Paketbetreuer gibt es Verbesserungspotenzial
  • Guix muss vermeiden, die Codeberg-Server übermäßig zu belasten, und den Speicherverbrauch von Repositories im Blick behalten
  • Als Lösung gibt es den Vorschlag, von neuen Beitragenden zu verlangen, Pull Requests mit dem AGit workflow zu erstellen
    • AGit ist unter Guix-Mitwirkenden bereits beliebt
    • Im Vergleich zum vertrauten allgemeinen Pull-Request-Workflow ist es jedoch weniger vertraut, weshalb manche es als „Downgrade“ sehen
    • Wie im Fall von Gentoo könnte ein „AGit fork“-Icon die Auffindbarkeit verbessern
  • Die Guix Foundation stimmte als Zeichen von Dank und Unterstützung dafür ab, Fördermitglied von Codeberg e.V. zu werden
  • Es wurde ein Pull Request eingereicht, der Forgejo und einen Service zu dessen Einrichtung in Guix ergänzt
    • Das geht in Richtung deklarativer Konfiguration und reproduzierbarer Forge-Bereitstellung innerhalb von Guix

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Lobste.rs-Kommentare

  • Es ist sehr interessant, die tatsächlichen Projektkennzahlen im Zusammenhang mit dem Wechsel zu Codeberg zu sehen. Persönlich habe ich viel zu viele Gründe, GitHub zu verlassen, daher hoffe ich, dass Codeberg das neue GitHub wird, aber ich bin auf einen eigenen Forgejo-Server umgezogen und nutze Codeberg jetzt als Backup-Ziel für alle Repositories

    • Ich weiß, dass das gut gemeint ist, aber ich denke, es wäre besser, wenn sich nicht alles bei Codeberg bündelt, sondern mehrere unabhängige Forges über ForgeFed miteinander kommunizieren.
      Wir brauchen nicht noch einen neuen Open-Source-zentrierten Hub
    • Ich glaube derzeit nicht, dass Forgejo bereits ausreichend skaliert, um diese Rolle zu tragen. Codeberg tut offenbar, was möglich ist, und ich hoffe, dass es besser wird, aber das dürfte Zeit brauchen
    • Alles, woran ich persönlich arbeite, ist letztlich vollständig zu Fossil umgezogen, und für Dinge, die ich anderen öffentlich zeigen will, habe ich einen eigenen Fossil-Server aufgesetzt.
      Bisher ist das sehr gut, und ich bevorzuge es eindeutig gegenüber git. Nach heutigen Maßstäben ist die Hürde nicht besonders hoch, aber sie ist da

  • Was mich nach dem Wechsel zu Codeberg wirklich frustriert hat, ist, dass es kaum Tools gibt, die git-Integration ordentlich unterstützen, und die meisten sind faktisch nur für GitHub / GitLab gedacht

    • Als Nutzer von magit forge treibt mir das die Tränen in die Augen

  • Ich verstehe nicht, warum der frühere Issue- und Patch-Tracker nur bis zum 1. Januar 2026 weitergeführt wird und danach nur noch Codeberg-Issues und Pull Requests unterstützt werden sollen.
    Wenn ein erheblicher Teil der Beitragenden den neuen Ablauf nicht mag, verstehe ich nicht, warum man den Wechsel erzwingt, und ich frage mich, ob es versteckte Kosten gibt, mehrere Abläufe parallel zu erlauben. Warum muss allen dieselbe Arbeitsweise aufgezwungen werden?
    Eine kleine Korinthenkackerei vielleicht, aber es sah nicht so aus, als hätte Codeberg mehrere bezahlte Mitarbeitende; soweit ich weiß, war es nur eine Person. Korrektur: Im vergangenen Dezember wurde eine zweite angestellte Person hinzugefügt