Was wünschen Sie sich von einer Forge?

• Nutzer von Jujutsu und anderen Versionsverwaltungssystemen sowie reine Git-Workflows, die von großen Forges nicht ausreichend abgedeckt werden, stehen zur Diskussion
• Im Mittelpunkt steht nicht die Implementierung als SPA/JS oder serverseitig gerendertes HTML, sondern wie ein Repository Versionsverwaltungsfunktionen darstellt und funktionieren lässt
• Es gibt Ideen wie Tangled, GitHubs stacked PRs und Forgefed, aber es ist schwer, einen Ort zu finden, an dem sich Nutzermeinungen zum Design sammeln
• Dazu gehören auch stacked PR/MR und alternative Kollaborationsmodelle; ein zentrales Thema ist die Versionsverwaltungserfahrung jenseits bestehender Forges
• Die Darstellung von Repository-Objekten wie Tags, Commits, Trees und Blobs ist bei den meisten Forges weitgehend ähnlich, und abgesehen von kleinen Formatunterschieden gibt es kaum Diskussionen dazu

[GN⁺]

Meinungen auf Lobste.rs

• Code-Review-Kommentare dürfen für mich absolut nicht außerhalb des Repositories selbst liegen
  Wertvollen historischen Kontext in Mailinglisten, Datenbank-Silos oder einer separaten Schicht zu speichern, die nicht an einen HEAD-Commit-Hash gebunden ist, ist grundsätzlich dieselbe Art von Risiko wie bei GitHub
  Fossil geht teilweise in diese Richtung, behandelt aber nur Issues; Code Review läuft dort weiterhin über E-Mail-Patches: https://fossil-scm.org/home/doc/tip/www/contribute.wiki
  Sobald diese Informationen erst einmal im Versionsverwaltungssystem liegen, kann man darauf tolle Web-UIs, RSS-Feeds und Mailinglisten aufsetzen
  Die zweite Funktion wäre eingebaute Unterstützung für eine Merge Queue. In nicht ganz trivialen Projekten sollten einzelne Beitragende nicht direkt in den main-Branch pushen dürfen; markiert man einen bestimmten Commit als „bereit zur Integration“, sollte ein Bot die vorgeschlagenen Änderungen serialisieren, CI optimal planen und main auf einen verifizierten Hash vorrücken
  Die dritte Funktion ist CI als isolierter Ausführungsdienst für heterogene Umgebungen wie Windows und macOS: https://gregoryszorc.com/blog/2021/…

  • Zusätzlich braucht es einen klaren Ansatz für Spam und Missbrauch
    Jeder sollte ein Konto anlegen und Issues eröffnen können, aber es darf keinen Spam geben
    GitHub macht das derzeit ziemlich gut. Man sieht gelegentlich Spam, aber nach einer Missbrauchsmeldung wird er sehr schnell entfernt. Dahinter steckt vermutlich eine Mischung aus Automatisierung und einem echten Team zur Klassifizierung
  • Gibt es derzeit Werkzeuge, die Code-Review-Kommentare im Repository selbst speichern?
    Ich schaue mir Fossil als „Forge“ für Hobbyprojekte an; viele externe Beiträge erwarte ich nicht, daher wäre Code Review eher ein Nice-to-have
  • Issues und Pull Requests möchte ich nicht im eigentlichen Repository haben
    Stattdessen will ich eine SQLite-DB, die sich synchronisieren, versenden und beliebig abfragen lässt
    Das nächste große Refactoring, an dem ich bei git-pr arbeiten will, ist, die SQLite-DB über einen SSH-Befehl verfügbar zu machen: ssh pr.pico.sh sql
    SQLite ist überall vorhanden, universell und allgemein nutzbar, aber es fehlt die Usability, es als Teil einer Forge zu behandeln
  • Code-Review-Kommentare ins Repository selbst zu legen, ist wirklich eine interessante Idee
    Ich frage mich nur, woran Kommentare später „angeheftet“ wären und wie Nutzer sie finden sollen, wenn Historie umgeschrieben wird, etwa durch Force-Pushes oder Squash-Merges
    Auf GitHub ist der Bezugspunkt der Pull Request, sodass man die Diskussion sehen kann, selbst wenn sich die enthaltenen Commits ändern
    Ich frage mich, ob dieses System ebenfalls ein separates PR-Konzept vorsieht, das im Repository gespeichert wird, oder ob eher etwas enger Integriertes gemeint ist
  • Ich bin mir nicht sicher, wie man das mit Commit-Hashes zusammenbringen soll und wie man auf stark schwankende Repository-Metadaten schauen sollte
    Andererseits nutze ich jj erfolgreich, also ist es in der Praxis vielleicht gar kein großes Problem

• Wenn man sowohl Gerrit als auch E-Mail nutzt, ist es schade, dass das Pull-Request-Modell so dominant ist
  Besonders dann, wenn Maintainer kleinere Stilprobleme nicht kommentieren, sondern einfach direkt beheben könnten und Beitragende sich um solche Stilfragen vermutlich kaum scheren
  Noch bedauerlicher ist aber, dass es für Darcs oder Pijul, die ich inzwischen immer häufiger nutze, überhaupt keinen Workflow außerhalb von E-Mail gibt
  Statt E-Mail hätte ich gern etwas XMPP-basiertes. Damit ließe sich in Echtzeit und verteilt an gerade in Arbeit befindlichen Patches zusammenarbeiten, etwa mit einem MUC pro Patchset
  MUCs können wie Voice-Chats geöffnet werden, und Dinge wie Rollen, Anhänge, Reaktionen, Suche, MAM, Moderation und Tombstoning nach Abschluss sind bereits per XEP definiert
  Für Abonnements könnte man PubSub nutzen und auch als Transport für CI
  Für echte Praxistauglichkeit bräuchte man wohl einen dedizierten Client, aber vieles könnte auch in beliebigen Clients einfach funktionieren
  Realistisch gesehen ist das vielleicht eher Ausdruck meiner jüngsten Faszination dafür, wie weit sich alte föderierte Technologien unerwartet ausdehnen lassen

• Code Review und Freigabe sind der Flaschenhals
  Die Kommunikation mit Code-Einreichenden hat sehr hohe Latenzen, dauert oft Wochen oder Monate und ist zudem unzuverlässig. Manche eröffnen einen PR und verschwinden dann
  Das GitHub-Modell, das von Hin-und-her-Kommunikation ausgeht, bricht hier völlig zusammen
  Es wäre gut, wenn man während des Reviews den Code direkt ändern und Commits wie mit git-absorb amendieren könnte. Wegen Kleinigkeiten wie Tippfehlern mit dem Einreichenden hin und her zu gehen, ist Zeitverschwendung, und der GitHub-Hack mit Edit Suggestion ist umständlich und macht die Historie unübersichtlich
  Ich will denselben Code nicht noch einmal reviewen. Wenn nur eine Funktion oder ein Commit problematisch ist, sollte ich den Rest vorab freigeben können und nach einem Force-Push des Einreichenden nicht alles noch einmal ansehen müssen
  Es wäre gut, wenn man nur Teile eines PR mergen oder Commits aus einem PR entfernen könnte, ohne ihn zu schließen. Manchmal will man zwar die Funktion selbst nicht, aber die dafür geleistete Vorarbeit ist es wert, erhalten zu bleiben; umgekehrt schleichen sich manchmal unnötige „Aufräumarbeiten“ oder Formatierungen ein
  Wenn der ursprüngliche Einreichende nicht reagiert, sollten andere an einem PR mitarbeiten, ihn verfeinern und Probleme beheben können. Im GitHub-Modell geht das theoretisch, praktisch wirkt es aber eher wie ein versteckter Trick, einen PR auf einen anderen PR zu bauen, und dieser Code samt Benachrichtigungen ist im Zielprojekt nicht sichtbar. Wenn Leute forken und dann PRs mit Korrekturen einreichen, entstehen nur Verwirrung und Merge-Konflikte
  Oft ist eingereichter Code eigentlich ganz brauchbar, man möchte aber noch kleine Verbesserungen. Aus Sicht des Einreichenden fühlt es sich frustrierend an, als würde der PR als Geisel gehalten, bis alle hübschen Abschlussarbeiten erledigt sind, und aus Sicht der Maintainer besteht das Risiko, sofort zu mergen und dann nie mehr Folgeverbesserungen zu bekommen, weil der Einreichende verschwindet. Es wäre gut, eine Möglichkeit zu haben, vorläufig zu mergen, aber mit der Verpflichtung, später noch aufzuräumen. Das könnte etwa bedeuten, in einen Staging-Branch zu mergen, aber nicht in den Stable-Branch zu cherry-picken, bis das FIXME behoben ist
  In populären Open-Source-Projekten gibt es oft genau 1 Person, die Code-Reviews und Freigaben geben kann, die das Projekt wirklich voranbringen, während 500 Personen beitragen und sich gegenseitig helfen wollen. Das GitHub-Modell nutzt diese überschüssige Beitragenden-Kapazität überhaupt nicht. Statt Zusammenarbeit zu fördern, verwandelt es sie in Krisen, Chaos und wütenden Gruppendruck. Es braucht bessere Unterstützung für Fork-Verwaltung und das Kopieren von Code zwischen Forks, damit andere experimentieren und ein Projekt voranbringen können, ohne an einer einzelnen Maintainer-Person zu hängen, und damit Maintainer leicht populäre, funktionierende Änderungen aus mehreren Forks auswählen können

  • Wenn der PR-Einreichende die entsprechende Sperre nicht aktiviert hat, kann der Repository-Eigentümer direkt in den PR-Branch pushen
    In Organisationen war diese Einstellung meines Wissens sogar der Standard, aber unabhängig davon kann man in diesem Fall per Force-Push direkt sauber nachbessern
    Für kleine Änderungen, die kein Hin und Her wert sind, mache ich das immer so
  • Wenn du denkst, dass Einreichende langsam sind, warte erst mal auf Maintainer-Reaktionen
    Das fühlt sich meist eher nach Monaten oder Jahren als nach Tagen an
    Manchmal bin ich selbst der Maintainer, und ich gebe zu, dass ich auch nicht immer schneller bin
  • Selbst wenn ein Web-Review-Interface den Code nicht direkt ändern kann, wäre es gut, wenn es deutlich näher an einer IDE läge
    Ich möchte Dinge wie „Gehe zur Definition“ oder Hover-Popups mit Signaturen und Doku-Kommentaren
    Das geht natürlich, wenn man den Branch auscheckt und im bevorzugten Editor reviewt, aber wie gesagt: Review ist der Flaschenhals
    Der Zusatzaufwand, beim Review mehrerer PRs ständig Branches zu wechseln, ist einfach zu groß

• Es braucht einen Einzelnutzerbetrieb, oder zumindest einen Einzelnutzer-Modus
  Warum sollte ich URLs wie https://code.chrismorgan.example/chrismorgan/repository-name in Kauf nehmen? https://code.chrismorgan.example/repository-name reicht doch
  Das meine ich völlig ernst, und unter https://github.com/go-gitea/gitea/issues/11028 sieht man, dass das offenbar viele wollen
  Einer der drei Hauptgründe, warum ich kein Fediverse-Konto habe, ist sogar, dass die Adressen schrecklich aussehen
  Wenn man wie bei einer primären E-Mail-Adresse @‌me@‌chrismorgan.info verwendet, könnte das für manche Leute einfach wie „@‌me“ aussehen, und @‌chrismorgan@‌chrismorgan.info finde ich schon beim Anschauen unangenehm
  Das hat ATProto sehr gut gelöst. Domainnamen eignen sich hervorragend als Handles, und wenn man mehrere Nutzer braucht, reichen Subdomains völlig aus
  Auch auf einer gemeinsamen Forge könnte man mit Subdomains logisch einen Einzelnutzercharakter herstellen. Es wäre interessant, sich statt github.com/chris-morgan einmal chris-morgan.github.com vorzustellen
  Ästhetik ist wichtig
  Der Weg zum Einzelnutzerbetrieb hat noch größere Folgen. Selbst wenn man etwas wie Mastodon auf einen Einzelnutzerfall heruntertrimmt, bleibt es schwergewichtig, während Fediverse-Projekte, die von Anfang an für Einzelnutzer entworfen wurden, dafür viel besser geeignet sind
  Ich möchte meinen Server selbst betreiben, aber lokal nur ich als Nutzer sein und wegen möglicher weiterer Nutzer keine Kompromisse eingehen müssen
  Das bedeutet bei Forges auch, dass ich nicht mit generischen Benutzernamen wie git pushen will, sondern wie bei normalem SSH mit einem Benutzernamen wie chris
  Wenn man unter einer Forge das Übliche versteht, ist Föderation natürlich nötig. Aber auf dem jeweiligen „Home Server“ hätte ich gern jeweils nur einen lokalen Nutzer

  • Wie handhabst du das bei E-Mail-Adressen?
    Wenn du eine Domain mit deinem Namen nutzt, hast du dort nicht ein ähnliches Problem?

• Mir gefiel Nesbitts Artikel zu diesem Thema
  Besonders bessere Kommunikation mit Downstream fand ich gut

• Es sollte möglich sein, lokales Code Review im Editor der Wahl zu machen
  Ich will nicht in einem trägen Web-Interface gefangen sein, das unveränderbare Schriftarten und grauenhaftes Syntax-Highlighting erzwingt
  Im Moment nutze ich einen Workflow mit eigenen Tools für Neovim, um Side-by-Side-Diffs gut lesbar zu machen, und mit dem Befehl git pr, um Pull Requests auszuchecken
  Aber sobald ich auch nur ein bisschen mehr will, etwa Review-Kommentare hinterlassen, bin ich von irgendeiner CLI oder einem Tool abhängig, das mit der GitHub-API spricht und in fünf Jahren vermutlich nicht mehr gepflegt wird
  Genauer gesagt braucht es nicht nur Werkzeuge, die lokal „ausführbar“ sind, sondern eher Local-first-Tools, die lokal mit Editor und Co. integriert sind
  Dass das schwer zu einer Funktion erster Klasse wird, liegt am hohen Aufwand. Ein einziges Web-Interface „funktioniert“ auf allen Plattformen und in allen Editor-Umgebungen, weil es den Nutzern aufgezwungen wird; engere Integration bedeutet aber bei N Editoren und Umgebungen auch N Integrationen
  Dasselbe gilt für CI. Ich möchte nicht einen Commit in einen Branch pushen und dann 15 Minuten warten, bis etwas anspringt, sondern Tests auf Linux, FreeBSD und macOS einfach starten können
  Etwa in der Form run-remotely some-command --on freebsd,linux,mac
  Im Kern wäre das ein Local-first- und dezentralisiertes CI-System, das zugleich ein zentrales System als Single Source of Truth unterstützt, um sicherzustellen, dass vor dem Merge aller Code dasselbe „freigegebene“ System durchlaufen hat
  Das geht über ein simples ssh user@host command ... hinaus, weil Quellcode kopiert, gecacht und nötige Abhängigkeiten installiert werden müssen, damit man jedes Mal denselben vertrauenswürdigen Zustand erhält

  • Ich denke in letzter Zeit über ganz Ähnliches nach
    Ich sehe das allerdings nicht als Forge-Funktion. Es sollte als Werkzeug für die Ausführung von Jobs bereitstehen, das auch ohne bestimmte Forge nutzbar ist und von jeder Forge aufgerufen werden kann
    Ich denke, es müsste ein wenig „treiberbasiert“ sein. Man sollte denselben Job vollständig lokal ausführen oder an ein entferntes System senden können, das ihn startet. Dieser Job könnte in einer virtuellen Maschine, in einem Container oder direkt laufen

• Es sollte auch Versionsverwaltungssysteme jenseits von Git unterstützen
  Issues, Wikis usw. sollten sich in praktischen Formaten importieren und exportieren lassen, damit man nicht an ein bestimmtes System gebunden ist
  Self-Hosting sollte ebenfalls einfach sein

  • Alle Nicht-Git-Versionsverwaltungssysteme zu unterstützen, ist schon eine ziemlich lange Liste
    Vermutlich gibt es einen kleineren Bereich, der in der Praxis wirklich wichtig ist
    Heptapod aus dem Schwesterkommentar ist für Mercurial, und sourcehut, ebenfalls
    Fossil hat eine eigene Forge, und allura, die Apache-Version von SourceForge, bietet Subversion an

• Es wäre schön, wenn eine Forge auf der CI-Ebene etwas Bazel-artiges anbieten würde
  Nicht im Sinn von „man kann Bazel in CI ausführen“, sondern in einer Form, die Menschen auf natürliche Weise dazu bringt, gute Tests und Builds mit Abhängigkeiten zu schreiben, statt grundlos CI-Zeit zu verbrennen
  In diesem Zusammenhang denke ich, dass das Modell „ein Projekt = ein Repository“ viele Probleme geschaffen hat
  Man könnte es als bessere Monorepo-Unterstützung beschreiben, aber im Kern sollten Dinge wie CI und Issues auf einen größeren Bereich als nur „das Top-Level dieses Verzeichnisses“ bezogen werden können
  Viele Projekte zerteilen Repositories wegen Forge- oder CI-Gründen, und in diesem Zustand zu arbeiten macht keinen Spaß
  Als Reviewer hätte ich außerdem gern Inline-Aufteilung von Patches
  Gemeint ist, dass ich die Teile auswählen und nur diese freigeben kann, die ich gut finde, sodass zufriedenstellende Teile integriert werden können
  Gestapelte PRs erscheinen mir immer noch als zu schwergewichtiges Konzept
  Wenn jemand „4 Dateien ändern“ möchte und das als einen einzigen PR betrachtet, sollte ein Reviewer sagen können: „Okay, diese 2 Dateien sind in Ordnung“, und dieses Bündel von Änderungen als separaten Teil des PR abspalten oder sogar nur dieses Fragment als eigenen Commit mergen können
  Auch heutige gestapelte PRs behandeln einen PR noch als atomare Einheit. In den meisten Systemen fühlt sich ein PR einfach zu schwer an

  • Nur eine Beobachtung: JetBrains war lange gegen Commits auf Hunk-Ebene
    Die Begründung war: „Das ist nur eine Teilmenge der Datei, daher kann man nicht wissen, ob es kompiliert“
    Ich stimme dieser Position überhaupt nicht zu, aber bei solchen Dingen in einer Web-Ansicht müsste man ziemlich vorsichtig sein, deshalb fiel mir das beim Lesen dieses Kommentars ein
    Natürlich einmal abgesehen von dem Punkt weiter oben, dass man als Repository-Eigentümer den Branch einfach per Force-Push in die bevorzugte Fassung bringen kann

• Es braucht eine CI/CD-Konfiguration ohne Aufwand
  make build, make test, make upload sollten reichen
  Den Rest kann man im Makefile lassen, von wo aus man dann zu einem besseren Build-System weitergehen kann
  Ich möchte von der Idee bis zu veröffentlichten Build-Artefakten in unter 2 Minuten kommen

  • Warum sollte man dafür ausgerechnet Make verwenden, das es noch dazu in mehreren Versionen gibt?
    Statt wie die meisten CI/CD-Systeme eine Konfigurationsdatei an einem bekannten Ort zu verwenden, könnte man einfach drei Shell-Skripte mit bekannten Namen in ein bekanntes Verzeichnis legen
    Als Bonus könnte man sie bei Bedarf für Windows auch als .bat-Dateien anlegen
  • Der Ansatz gefällt mir, aber vermutlich braucht man eine Möglichkeit zur Installation von Abhängigkeiten
    Das kann je nach Betriebssystem unterschiedlich sein, und man möchte es vielleicht nicht ins Makefile packen
  • Ich baue gerade ein Local-first-CI mit eigener Isolierung: https://ci.pico.sh
    Der Vorteil ist, dass alle Jobs in ihrer eigenen pty unter zmx laufen
    Man kann sich an einen fehlgeschlagenen Job anhängen und ihn mit Pfeil nach oben und Enter erneut starten

• Ich hätte gern Sicherheitshinweise mit Guardrails, damit qualitativ hochwertige Daten veröffentlicht werden
  Es braucht ein commit-zentriertes Ökosystem, damit alle Projekte sinnvolle Daten veröffentlichen können, und für Projekte, die es möchten, sollte es auch eine Integration geben, mit der sie direkt CVEs ausstellen können