Qu’attendez-vous d’une forge ?

• Les utilisateurs de Jujutsu et d’autres systèmes de gestion de versions discutent de workflows Git purs que les principales forges prennent insuffisamment en charge
• Le principal sujet d’intérêt n’est pas le mode d’implémentation, comme SPA/JS ou du HTML rendu côté serveur, mais la façon dont le dépôt représente et fait fonctionner les fonctionnalités de gestion de versions
• Il existe des idées comme Tangled, les stacked PRs de GitHub ou forgefed, mais il est difficile de trouver un espace où recueillir les avis des utilisateurs sur la conception
• Cela inclut les stacked PR/MR et des modèles de collaboration alternatifs, et la question centrale porte sur une expérience de gestion de versions allant au-delà des forges existantes
• L’affichage des objets du dépôt comme les tags, commits, arbres et blobs est globalement similaire d’une forge à l’autre, et il y a très peu de discussions en dehors de différences de format mineures

[GN⁺]

Avis sur Lobste.rs

• Je ne pourrais absolument pas utiliser des commentaires de revue de code s’ils ne faisaient pas partie du dépôt lui-même
  Stocker un contexte historique précieux dans une mailing-list, un silo de base de données ou une couche séparée qui n’est pas ancrée à un hash de commit HEAD, c’est fondamentalement le même type de risque que GitHub
  Fossil va un peu dans cette direction, mais ne traite pour l’instant que les issues, et pour la revue de code c’est encore le modèle des patchs par e-mail : https://fossil-scm.org/home/doc/tip/www/contribute.wiki
  Une fois que ces informations sont dans le système de contrôle de version, on peut construire par-dessus une belle interface web, un flux RSS et une mailing-list
  La deuxième fonctionnalité, c’est le support intégré d’une merge queue. Dans tout projet non trivial, les contributeurs individuels ne devraient pas pouvoir pousser directement sur la branche main ; quand un commit donné est marqué comme « prêt à être intégré », un bot devrait sérialiser les changements proposés, planifier le CI de manière optimale, puis faire avancer main vers un hash validé
  La troisième fonctionnalité, c’est un CI comme exécuteur de tâches isolé dans des environnements hétérogènes comme Windows, macOS, etc. : https://gregoryszorc.com/blog/2021/…

  • En plus, il faut une approche claire pour gérer le spam et les abus
    N’importe qui devrait pouvoir créer un compte et ouvrir une issue, mais il ne devrait pas y avoir de spam
    Aujourd’hui, GitHub s’en sort plutôt bien sur ce point. On voit du spam de temps en temps, mais après signalement pour abus il est retiré très vite. Il y a probablement derrière un mélange d’automates et d’une vraie équipe humaine de tri
  • Est-ce qu’il existe aujourd’hui des outils qui stockent les commentaires de revue de code dans le dépôt lui-même ?
    Je regarde Fossil comme « forge » pour des projets perso, mais je ne m’attends pas à avoir beaucoup de contributions externes, donc la revue de code serait juste un plus appréciable
  • Je n’ai pas envie de mettre les issues et les pull requests dans le dépôt lui-même
    À la place, je veux une base SQLite qu’on puisse synchroniser, envoyer et interroger librement
    La prochaine grosse refonte prévue dans git-pr, c’est d’exposer une base SQLite via une commande SSH : ssh pr.pico.sh sql
    SQLite est disponible partout, polyvalent, mais il lui manque l’ergonomie d’un usage comme composant intégré d’une forge
  • Mettre les commentaires de revue de code dans le dépôt lui-même est une idée vraiment intéressante
    En revanche, je me demande où les commentaires resteraient « ancrés » et retrouvables par les utilisateurs dans les cas de réécriture d’historique, comme un force-push ou un squash merge
    Sur GitHub, ce point d’ancrage est la Pull Request, donc on peut toujours voir la discussion même si les commits inclus changent
    Je me demande si ce système aurait aussi une notion séparée de PR stockée dans le dépôt, ou s’il faut imaginer quelque chose de plus étroitement intégré
  • Je ne vois pas très bien comment combiner ça avec les hashes de commit, ni quoi penser du problème d’un grand mouvement dans les métadonnées du dépôt
    Cela dit, j’utilise bien jj, donc en pratique ce n’est peut-être pas un gros problème

• Pour avoir utilisé à la fois Gerrit et l’e-mail, je trouve dommage que le modèle pull request soit devenu aussi dominant
  C’est particulièrement vrai quand un mainteneur pourrait simplement corriger lui-même un détail de style au lieu de laisser un commentaire, et que le contributeur n’accordera probablement pas tant d’importance que ça à ce style
  Mais ce qui est encore plus regrettable, c’est qu’il n’existe aujourd’hui aucun workflow non fondé sur l’e-mail pour Darcs ou Pijul, alors qu’on les utilise de plus en plus
  Je préférerais quelque chose de basé sur XMPP plutôt que sur l’e-mail. On pourrait avoir de la collaboration distribuée en temps réel sur des patchs en cours, avec par exemple un MUC par patchset
  Les MUC peuvent s’ouvrir comme un salon vocal, et des fonctions comme les rôles, pièces jointes, réactions, recherche, MAM, modération ou tombstoning après clôture sont déjà définies par des XEP
  On pourrait utiliser PubSub pour les abonnements, et aussi comme moyen de transport pour le CI
  Pour que ce soit vraiment pratique, il faudrait probablement un client dédié, mais beaucoup de fonctions pourraient simplement marcher avec n’importe quel client
  En réalité, c’est peut-être surtout le reflet de mon intérêt récent pour la manière dont de vieilles technologies fédérées s’étendent de façon inattendue

• Le code review et l’approbation sont le goulet d’étranglement
  La communication avec la personne qui a soumis le code a une latence énorme, parfois de plusieurs semaines ou mois, et elle n’est pas fiable non plus. Il arrive que des gens ouvrent une PR puis disparaissent
  Le modèle GitHub, qui suppose des allers-retours, s’effondre complètement dans ce cas
  J’aimerais pouvoir modifier directement le code pendant la revue et amender les commits comme avec git-absorb. Faire des allers-retours avec l’auteur pour des détails mineurs comme des coquilles, c’est une perte de temps, et le hack des Edit Suggestion sur GitHub est pénible et salit l’historique
  Je n’ai pas envie de relire le même code. Si le problème ne concerne qu’une fonction ou un seul commit, le reste devrait pouvoir être approuvé à l’avance, et il ne devrait pas être nécessaire de tout revoir quand l’auteur corrige via force-push
  Il devrait être possible de merger seulement une partie d’une PR, ou d’en retirer des commits sans fermer la PR. Parfois on ne veut pas la fonctionnalité en elle-même, mais le travail préparatoire vaut la peine d’être conservé ; inversement, il arrive que du « nettoyage » ou du formatage inutile s’y glisse
  Quand l’auteur initial ne répond pas, d’autres personnes devraient pouvoir collaborer sur la PR, l’affiner et résoudre les problèmes. C’est théoriquement possible dans le modèle GitHub, mais en pratique cela ressemble davantage à une technique cachée consistant à faire une PR sur une autre PR, et ce code comme ces notifications restent invisibles pour le projet cible. Quand les gens forkent puis ouvrent une PR corrective, cela ne crée que de la confusion et des conflits de merge
  Il arrive souvent que le code soumis soit globalement correct, mais qu’on veuille encore quelques améliorations. Du point de vue du contributeur, c’est frustrant d’avoir l’impression que la PR est prise en otage jusqu’à ce que toutes les finitions soient faites ; du point de vue du mainteneur, merger immédiatement fait courir le risque que l’auteur disparaisse et que les améliorations de suivi ne soient jamais faites. J’aimerais une façon de merger temporairement avec l’obligation explicite de faire le ménage plus tard. Par exemple, on pourrait merger dans une branche de staging, mais ne pas cherry-pick vers la branche stable tant que les FIXME ne sont pas résolus
  Dans certains projets open source populaires, on se retrouve avec une seule personne capable de faire avancer le projet en relisant et approuvant le code, alors qu’il y a 500 personnes qui veulent contribuer et s’entraider. Le modèle GitHub n’exploite absolument pas cette capacité contributive excédentaire. Au lieu d’aider à collaborer, il transforme cela en crise, confusion et pression de groupe en colère. Il faudrait mieux gérer les forks et la copie de code entre forks, pour que d’autres puissent expérimenter et faire progresser le projet sans être bloqués par un unique mainteneur, et pour que le mainteneur puisse facilement choisir, parmi plusieurs forks, les changements populaires et éprouvés en pratique

  • Si l’auteur de la PR n’a pas activé le réglage qui l’empêche, le propriétaire du dépôt peut pousser directement sur la branche de la PR
    Dans les organisations, il me semble que c’était la valeur par défaut, mais dans tous les cas cela permet de corriger proprement soi-même via force-push
    C’est ce que je fais toujours pour les petites corrections qui ne justifient pas un aller-retour
  • Si vous trouvez l’auteur lent, attendez de voir ce que c’est que d’attendre une réponse de mainteneur
    En général, cela se mesure plutôt en mois voire en années
    Il m’arrive d’être moi-même mainteneur, et j’admets que je ne suis pas toujours plus rapide que ça
  • Même si l’interface web de revue ne permet pas de modifier directement le code, j’aimerais qu’elle se rapproche beaucoup plus d’un IDE
    Je veux des fonctions comme aller à la définition, ou des infobulles au survol qui affichent la signature ou la documentation
    On peut l’obtenir en checkoutant la branche et en relisant dans son éditeur préféré, mais comme je l’ai dit, la revue est le goulet d’étranglement
    Quand on doit passer d’une branche à l’autre pour relire plusieurs PR, la surcharge supplémentaire est trop importante

• Il faut un mode utilisateur unique, ou au moins un mode utilisateur unique
  Pourquoi devrais-je supporter une URL comme https://code.chrismorgan.example/chrismorgan/repository-name ? https://code.chrismorgan.example/repository-name devrait suffire
  Je le pense sincèrement, et quand on voit https://github.com/go-gitea/gitea/issues/11028, il est clair que beaucoup de gens veulent ça
  L’une des trois principales raisons pour lesquelles je n’ai pas de compte Fediverse, c’est aussi que les adresses sont horribles
  Si j’utilise @‌me@‌chrismorgan.info comme adresse principale, certaines personnes risquent de la voir simplement comme « @‌me », et @‌chrismorgan@‌chrismorgan.info me répugne rien qu’à la vue
  C’est un point sur lequel ATProto a été très bon. Un nom de domaine fait un excellent handle, et si plusieurs utilisateurs sont nécessaires, des sous-domaines suffisent largement
  Sur une forge partagée aussi, on pourrait sans doute utiliser des sous-domaines pour obtenir quelque chose qui ressemble logiquement à un usage mono-utilisateur. Au lieu de github.com/chris-morgan, imaginez chris-morgan.github.com, ce serait presque amusant
  L’esthétique compte
  Aller vers l’utilisateur unique a aussi des conséquences plus larges. Si on réduit quelque chose comme Mastodon à un seul utilisateur, ça reste lourd, alors qu’un projet Fediverse conçu dès le départ pour un seul utilisateur est bien plus adapté à cet usage
  Je veux administrer moi-même mon serveur, avec un seul utilisateur local : moi, sans devoir faire de compromis pour l’éventualité d’autres utilisateurs
  Cela veut aussi dire que, pour pousser, je voudrais utiliser un nom d’utilisateur ordinaire comme chris, comme en SSH classique, et non un nom générique comme git qu’emploient les forges
  Si on parle d’une forge au sens habituel du terme, la fédération est évidemment nécessaire. Mais sur le « serveur maison » de chacun, ce serait bien de n’avoir qu’un seul utilisateur local

  • Et pour les adresses e-mail, comment faites-vous ?
    Si vous utilisez un domaine à votre nom, n’y a-t-il pas un problème similaire là aussi ?

• J’ai bien aimé l’article de Nesbitt sur ce sujet
  En particulier, l’idée d’une meilleure communication avec l’aval m’a plu

• Il devrait être possible de faire de la revue de code locale dans l’éditeur de son choix
  Je n’ai pas envie d’être enfermé de force dans une interface web lourde avec une police imposée et une coloration syntaxique affreuse qu’on ne peut pas changer
  Aujourd’hui, j’utilise un workflow avec des outils maison pour Neovim qui rendent les diff côte à côte agréables à lire, et la commande git pr pour checkout les pull requests
  Mais dès qu’on veut un tout petit peu plus, comme laisser des commentaires de revue, on se retrouve dépendant d’un CLI maintenu par quelqu’un dont il y a peu de chances qu’il existe encore dans cinq ans, ou d’un outil qui parle à l’API GitHub
  Plus précisément, il ne faut pas seulement des outils « exécutables » en local, mais davantage d’outils local-first intégrés localement à l’éditeur, etc.
  Si c’est difficile à proposer comme fonctionnalité de premier rang, c’est parce que l’effort nécessaire est énorme. Une interface web unique « fonctionne » sur toutes les plateformes et dans tous les environnements d’édition en imposant son cadre à l’utilisateur, alors qu’une intégration plus poussée exige N intégrations s’il y a N éditeurs et environnements
  C’est pareil pour le CI. Je veux pouvoir lancer facilement des tests sur Linux, FreeBSD et macOS, sans pousser un commit sur une branche puis attendre 15 minutes qu’il soit pris en charge
  Quelque chose comme run-remotely some-command --on freebsd,linux,mac suffirait
  En gros, il faudrait un système de CI à la fois local-first et décentralisé, tout en prenant aussi en charge un système central servant de source unique de vérité, pour garantir que tout le code passe bien par le même système « approuvé » avant merge
  Cela va au-delà d’un simple ssh user@host command ..., parce qu’il faut copier le code source, gérer le cache, installer les dépendances nécessaires, etc., afin d’obtenir à chaque fois le même état fiable

  • J’ai des réflexions similaires en ce moment
    Cela dit, je ne pense pas que ce soit une fonctionnalité de forge. Ce devrait être fourni comme un outil d’exécution de tâches utilisable sans forge particulière et appelable depuis n’importe quelle forge
    À mon avis, il faudrait quelque chose d’un peu « basé sur des drivers ». On pourrait exécuter la même tâche entièrement en local, ou l’envoyer à un système distant pour qu’il la lance. Cette tâche pourrait tourner dans une machine virtuelle, un conteneur, ou directement sur la machine

• Il faut aussi prendre en charge des systèmes de contrôle de version autres que Git
  Il faut pouvoir importer et exporter les issues, le wiki, etc. dans des formats pratiques pour ne pas se retrouver enfermé dans un système donné
  L’auto-hébergement doit aussi être simple

  • Prendre en charge tous les systèmes de contrôle de version autres que Git, cela fait une liste assez longue
    J’imagine qu’il y a en réalité un sous-ensemble important à viser
    Heptapod dans le commentaire voisin est pour Mercurial, et sourcehut aussi
    Fossil a sa propre forge, et allura, la version Apache de SourceForge, propose Subversion

• J’aimerais qu’une forge offre au niveau CI quelque chose de proche de Bazel
  Pas au sens de « on peut exécuter Bazel dans le CI », mais au sens d’un système qui pousse naturellement les gens à écrire de bons tests et de bons builds avec dépendances, afin d’éviter de brûler du temps de CI sans raison
  Sur le même sujet, je pense que le modèle « un projet = un dépôt » a créé beaucoup de problèmes
  On peut l’appeler un meilleur support des monorepos, mais fondamentalement les choses comme le CI et les issues devraient pouvoir avoir une portée plus large que « la racine de ce répertoire »
  Beaucoup de projets se retrouvent éclatés en plusieurs dépôts pour des raisons liées à la forge ou au CI, et travailler comme ça n’a rien d’amusant
  En tant que reviewer, je voudrais aussi du découpage de patch inline
  Je veux pouvoir sélectionner les parties que je juge bonnes et approuver seulement celles-là, afin d’intégrer ce qui est satisfaisant
  Je trouve que les PR empilées restent malgré tout un concept trop lourd
  Si quelqu’un dit « je veux modifier 4 fichiers et je vois ça comme une seule PR », le reviewer devrait pouvoir répondre « très bien, ces 2 fichiers-là me conviennent », puis soit en faire une section distincte de la PR, soit même merger uniquement ce morceau comme commit séparé
  Les PR empilées actuelles traitent encore la PR comme une unité atomique. Dans la plupart des systèmes, j’ai l’impression que la PR est trop lourde

  • Simple observation, mais JetBrains s’est longtemps opposé à la validation au niveau des hunks
    Leur raison était : « ce n’est qu’un sous-ensemble du fichier, donc on ne sait pas si ça compile »
    Je ne suis pas du tout d’accord avec cette position, mais en voyant ce commentaire j’y ai repensé, parce qu’il faut effectivement faire très attention si l’on veut permettre ce genre d’opération dans une vue web
    Bien sûr, sans même parler du fait que, comme le disait un commentaire plus haut, si on est propriétaire du dépôt on peut toujours faire un force-push de la version qu’on préfère sur la branche

• Il faut une configuration CI/CD sans effort
  Il suffit d’avoir make build, make test, make upload
  Qu’on laisse le reste dans le makefile, et cela pourra ensuite évoluer vers un meilleur système de build
  Je veux pouvoir passer de l’idée à l’artefact publié en moins de deux minutes

  • Pourquoi faut-il forcément utiliser Make, qui existe en plusieurs versions ?
    Au lieu de ça, comme la plupart des systèmes de CI/CD le font avec un fichier de configuration à un emplacement connu, il suffirait de mettre trois scripts shell à nom connu dans un répertoire connu
    Et en bonus, s’il faut une build Windows, on pourrait aussi les faire en .bat
  • Cette approche me plaît, mais il faudra probablement un moyen de gérer l’installation des dépendances
    Cela peut varier selon le système d’exploitation, et on n’a pas forcément envie de le mettre dans le makefile
  • Je suis en train de construire un CI local-first capable d’apporter lui-même l’isolation : https://ci.pico.sh
    L’avantage, c’est que tous les jobs tournent dans leur propre pty sous zmx
    On peut s’attacher à un job en échec, puis le relancer avec flèche haut et Entrée

• Je veux des avis de sécurité avec des garde-fous pour garantir la publication de données de qualité
  Il faut un écosystème centré sur les commits pour que tous les projets puissent publier des données pertinentes, ainsi qu’une intégration permettant aux projets qui le souhaitent d’émettre eux-mêmes des CVE