Si je créais mon propre GitHub

 (matduggan.com)
5 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Les forge modernes comme GitHub, GitLab et Gitea partagent un modèle de type GitHub, mais dans le travail réel, l’essentiel se passe davantage dans les fonctions de forge comme les PR, Actions, Issues et Releases que dans git
  • Une nouvelle forge devrait pouvoir exécuter à distance des hooks pre-commit obligatoires qui donnent un retour avant le push, et non après le commit, afin de réduire les séries de commits répétitifs comme Feature, fix, actually fix, asdfasdf
  • L’approbation des PR devrait dépasser le simple binaire approbation/refus, prendre en charge des approbations faibles et des marqueurs « à revoir plus tard » comme Gerrit, et laisser passer plus souplement les petits changements quand l’auteur est mainteneur et qu’un LLM les juge à faible risque
  • Les Stacked PR devraient être des fonctions de première classe de la forge et du VCS, et le dépôt local devrait représenter l’état complet du dépôt, y compris les approbations de PR et les issues, pas seulement le code
  • La combinaison souhaitée serait JJ comme VCS, une nouvelle forge hébergeable en petites unités, et des Actions prenant en charge les signatures, les SHA et l’exécution hors ligne ; à l’ère où GitHub est la forge géante par défaut, il n’existe pas encore d’alternative nette

Les problèmes des forges modernes

  • GitHub, GitLab et Gitea suivent presque tous le même modèle de conception malgré des différences de détail, et ressemblent surtout à une reprise par d’autres outils du modèle industriel imposé par GitHub
  • La plupart des fonctions des forges actuelles ont très peu de lien direct avec git lui-même, et le client est déconnecté des usages réels
  • git est un système de gestion de versions distribué bien adapté à des environnements comme le développement du noyau, avec un workflow fondé sur une forte confiance, où l’on envoie des patchs par e-mail aux mainteneurs, qui gèrent leur périmètre et décident de la fusion
  • Mais dans la plupart des entreprises, git sert surtout à pull/push du code depuis un dépôt stocké sur une forge centrale, et le travail important se fait dans la forge
    • Les Pull Requests deviennent un moyen d’imposer le principe des quatre yeux
    • GitHub Actions exécute les tests et le linting sur les Pull Requests pour vérifier le bon fonctionnement et le respect des exigences de l’organisation
    • L’identité des utilisateurs dans la forge devient le critère de vérification des utilisateurs
    • Les Issues servent à suivre les problèmes de code, et les Releases à produire les versions que les utilisateurs téléchargeront
  • Dans ce type de workflow, les fonctions de forge construites au-dessus de git pèsent davantage que git lui-même ; si l’on créait une nouvelle forge, il y aurait donc moins de raisons de rester absolument lié à la contrainte git

Fonctions souhaitées dans une nouvelle forge

  • Le feedback doit arriver avant le commit, pas après

    • On voit souvent dans les PR des suites de commits du type Feature, fix, fix, actually fix, please, asdfasdf
    • Quand la boucle de feedback intervient après le commit, les utilisateurs souffrent à corriger tard dans la nuit
    • La forge devrait fournir des hooks pre-commit obligatoires qui exécutent des tâches à distance afin que l’utilisateur reçoive du feedback avant le push

  • L’approbation des PR est trop binaire

    • Aujourd’hui, une PR est soit approuvée, soit non approuvée, alors que la revue de code réelle comporte de nombreuses nuances intermédiaires
    • Une réaction humaine comme « c’est bon pour l’instant, on traitera ça plus tard » devrait aussi pouvoir être exprimée par un bouton
    • Gerrit propose un meilleur modèle sur ce point
    • Si un mainteneur donne une approbation faible, il devrait être possible de la marquer pour y revenir plus tard

  • Les politiques de PR doivent être plus souples

    • Tous les changements ne nécessitent pas une revue à quatre yeux, surtout dans un monde où les LLM existent
    • Le coût d’attendre qu’un ingénieur senior laisse juste un LGTM sur une PR de quatre lignes est excessif
    • Si l’auteur est mainteneur et qu’un LLM estime le risque faible ou nul, il devrait être plus facile d’autoriser un passage direct

  • Les Stacked PR doivent être une fonction de première classe

    • Les Stacked PR facilitent la revue et la compréhension
    • Elles doivent être traitées comme des citoyennes de première classe dans la forge et le VCS, et non comme une surcouche fournie par un outil externe au VCS

  • Une forge ne doit pas chercher à tout faire

    • Le suivi d’issues est nécessaire, mais probablement pas un tableau Kanban
    • L’utilité d’un Wiki est également discutable
    • Les outils qui veulent tout intégrer finissent par perdre en qualité ; ajouter des fonctions est facile, mais le coût de maintenance continue d’exister indépendamment du taux d’adoption
    • Dès que quelqu’un commence à l’utiliser quelque part, on se retrouve lié à cette fonction

  • L’unité d’hébergement est trop grande

    • Faire tourner GitHub Enterprise est un gros chantier, et GitLab reste lui aussi relativement lourd à exploiter
    • Ces produits sont des systèmes complexes avec beaucoup de pièces en mouvement
    • Il devrait être possible de créer des unités d’hébergement individuelles plus petites, puis de les relier pour former une organisation
    • Il n’est pas nécessaire d’avoir une fédération mondiale, et créer des comptes par organisation peut être acceptable, mais une organisation devrait être assez flexible pour dire « ces 12 Raspberry Pi constituent mon organisation »

  • Le dépôt local doit représenter l’ensemble du dépôt, pas seulement le code

    • La copie locale devrait représenter non seulement le code, mais tout le dépôt, y compris les approbations de PR et les issues
    • On devrait pouvoir approuver une PR dans le même VCS que celui qui sert à versionner le code
    • On devrait pouvoir parcourir les issues comme on parcourt les fichiers locaux

  • Il ne faut pas toujours payer le coût du stockage de tout l’historique

    • Pour bien travailler en équipe, il faut être en ligne ; il n’est donc pas nécessaire de forcer en permanence le coût de stockage complet
    • Le VCS et la forge devraient fonctionner ensemble
    • Lors d’un clone de dépôt, on ne recevrait qu’un historique limité, puis, si l’on veut remonter dans le passé, un worker irait chercher dans le VCS ce qu’il faut
    • Il ne faut pas continuer à envoyer à la forge d’énormes demandes de clone sous prétexte qu’un utilisateur pourrait un jour reconstruire la forge à partir de l’historique complet du projet

  • Les Actions doivent être signées, attachées à des SHA et utilisables hors ligne

    • Les Actions étant importantes, elles doivent prendre en charge les signatures, les SHA et l’usage hors ligne
    • Si on le souhaite, on devrait pouvoir récupérer les tarballs de toutes les actions, les placer dans le dépôt, et indiquer au système d’utiliser pour l’action de checkout celle présente dans le dépôt local au lieu d’en chercher une externe
    • Si l’on spécifie latest, le fonctionnement devrait consister à ouvrir une PR qui place dans le dépôt le tarball le plus récent, à la manière de Dependabot aujourd’hui
    • Les Actions devraient aussi pouvoir s’exécuter sur la machine locale via le même VCS si on le souhaite

Des outils font déjà une partie du travail, mais il faut les combiner

  • Il existe déjà beaucoup d’outils qui couvrent une partie de ces besoins
  • Ce qu’il faut, c’est prendre ces outils, les assembler et les faire correctement s’emboîter
  • La combinaison souhaitée est JJ comme VCS, un nouveau système comme forge, et l’idée qu’un utilisateur puisse se satisfaire durablement d’un simple Raspberry Pi comme forge
  • La nouvelle forge devrait être conçue autour de concepts modernes comme le stockage objet, le shallow clone et les requêtes continues d’un bot LLM

Les fissures dans l’époque où GitHub est la valeur par défaut

  • Si GitHub faisait bien son travail, il n’y aurait pas besoin d’écrire ce genre de proposition
  • GitHub est la valeur par défaut, et essayer de convaincre d’aller au-delà de la valeur par défaut est souvent proche d’une perte de temps
  • Jusqu’en 2026, utiliser une forge supposait d’avoir une raison très forte de ne pas choisir l’outil utilisé par tout le monde
  • Jusqu’à récemment, les autres forges étaient perçues moins comme de vrais choix désirables que comme des solutions de remplacement
  • Mais la forge géante unique est en train de se fissurer, et l’alternative n’a pas encore été construite
  • Les gens qui ont de l’argent sont occupés avec des fusées, ceux qui ont du goût sont occupés par leur vrai métier, et les autres ouvrent à minuit une PR nommée asdfasdf, attendent les vérifications automatiques, puis se demandent quand l’outil qu’ils utilisent toute la journée a cessé d’être conçu pour ses utilisateurs

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Hacker News

  • La critique selon laquelle la validation de PR est trop binaire semble contradictoire. La validation d’une PR consiste à accorder une autorisation, donc cela finit forcément par être booléen : soit on peut fusionner le code, soit on ne le peut pas
    Ce dont il est question ici ressemble davantage à un mécanisme permettant de se sentir un peu mieux en validant du code qu’on n’aime pas, avec un commentaire du type « à revoir plus tard... ». Il suffit d’ouvrir un nouveau ticket

    • Gerrit a des notes allant de -2 à +2
      -2 : mauvaise idée, à ne pas faire
      -1 : bonne idée, mais nécessite des améliorations
      +1 : ça semble bon, mais je n’ai ni les connaissances ni l’autorité pour valider
      +2 : validé
    • J’aimerais un bouton qui dise : « valider et fusionner ces 3 commits maintenant ; ces 2 autres doivent être retravaillés »
    • Il arrive aussi que du code soit validé sans être fusionné. Dans ce cas, un mainteneur peut ajouter des modifications et les appliquer manuellement, puis indiquer l’auteur de la PR comme co-auteur du commit de modification
    • Le plus gros problème semble être que GitHub est trop séparé du système de suivi d’issues. Il faut sans cesse tout resynchroniser manuellement ; Linear en gère une partie, mais ce n’est pas idéal
    • « Soit on peut fusionner le code, soit on ne le peut pas » : on dirait bien que tu n’es pas intuitionniste

  • C’est vrai de dire que « Y en fait une partie », mais tangled.org fait en réalité presque tout cela

    1. Utiliser JJ comme système de gestion de versions : tangled prend en charge les PR empilées via les jj change-id. https://blog.tangled.org/stacking tangled lui-même est largement construit ainsi : https://tangled.org/tangled.org/core/pulls
    2. Un forge capable de tourner longtemps sur un Raspberry Pi : c’est aussi possible. Le shim du serveur git est très léger ; ce n’est guère plus qu’une couche XRPC au-dessus d’un dépôt git et d’une base sqlite3. Certains le font tourner sur une carte RISC-V avec 512 Mo de RAM
    3. Les Actions sont importantes et doivent pouvoir s’exécuter en local : je pense que cette exigence rate un peu la cible. Le confinement, l’exécution partout et la gestion du cross-build relèvent en général du système de build. Ce serait vraiment bien si ces résultats de build pouvaient ensuite être « promus » dans le forge lui-même
    • Je suis surpris de voir apparaître le Raspberry Pi pour héberger des données essentielles au workflow. J’ai trop souffert autrefois de la corruption des cartes SD ; je me demande si, aujourd’hui, ils utilisent des disques NVME
    • Oui, c’est bien le rôle du système de build. Mais ce que les gens veulent résoudre avec des Actions exécutables en local, ce n’est généralement pas l’échec du build en lui-même, c’est l’intégration de l’ensemble
      la définition YAML, les secrets, les commandes exactes à exécuter, la manière de restaurer les outils et les caches. Un système de build peut en prendre une partie en charge, mais les primitives fournies par GHA sont très pauvres. Au final, tout ramène au problème de faire tourner l’ensemble du système ailleurs, c’est pourquoi ces systèmes finissent souvent par se construire par tâtonnements
    • Oui, et même au-delà, l’idée serait d’étendre le concept de build confiné afin de pouvoir l’exécuter facilement en local ou partout où l’on a des ressources de calcul
      Le problème fondamental visé ici, c’est qu’il est extrêmement pénible de boucler entre changements, commits et appels réseau jusqu’à ce que la CI passe au vert. La meilleure façon d’éviter cette boucle est tout simplement de ne jamais écrire de bugs ! Je plaisante
    • Radicle et Tangled passent tous deux à côté d’un point essentiel. Ils servent au travail collaboratif public, mais qu’en est-il des dépôts privés ? Beaucoup d’utilisateurs ont des side projects et utilisent GitHub private pour cela
      Quand on apprend GitHub, on finit aussi par démarrer ses projets publics sur GitHub. Tant qu’on ne peut pas créer des dépôts privés pour ses side projects, ce sera difficile à adopter largement. Ce que veulent les gens, c’est pouvoir créer un dépôt privé, partir quelques mois, puis revenir et le retrouver tel quel en attente
    • Waouh, la prise en charge de jujutsu par Tangled, c’est exactement ce que je cherchais. Mon week-end va disparaître dans une installation self-hosted

  • Si vous voulez cloner seulement un historique limité et récupérer les anciennes données à la demande, il suffit d’utiliser un blobless clone
    git clone --filter=blob:none
    On récupère l’historique, et les blobs seulement quand ils sont nécessaires. GitHub a un bon article à ce sujet : https://github.blog/open-source/git/get-up-to-speed-with-par...

  • Quand la solution devient le problème, cela ouvre une opportunité de rupture disruptive. On en parle beaucoup en ce moment, et je me demande si, avant que GitHub ne corrige sa trajectoire, l’une des nombreuses nouvelles alternatives finira par prendre de l’élan

    • À mon avis, le problème est que Microsoft a complètement fait all-in sur l’IA. Il n’y a plus de retour en arrière, et GitHub ne peut qu’en subir les conséquences
      La communication de Microsoft dira que l’IA est la solution à tout, mais dans la réalité les mêmes problèmes reviendront sans cesse. Les pannes de GitHub ne sont peut-être pas directement liées à l’IA, mais comme la stratégie de Microsoft a déjà changé, la plupart des décisions seront alignées sur un contrôle descendant centré sur l’IA. Le fait que les workflows des utilisateurs de GitHub soient cassés n’est, pour Microsoft, qu’un sujet secondaire au mieux, et ce problème reviendra encore et encore. On peut avoir trois mois de calme, mais je suis certain à 100 % qu’on reverra bientôt un nouveau feuilleton sur le déclin de GitHub. Ghostty ne sera pas le dernier. Reste à voir si des alternatives émergeront, mais encore faut-il qu’elles ne soient pas mauvaises, et beaucoup de sites web sont franchement médiocres
    • Je construis mes outils moi-même. Je pense que les gens devraient aussi construire leurs propres outils
      Peut-être qu’à l’avenir, au lieu de logiciels payants ou open source, on recevra des lots de documents d’exigences pour un code forge, une sorte de recette. Chacun cuira le sien, puis l’adaptera à ses usages et à ses goûts

  • Je pense qu’il existe un créneau pour un service git beaucoup plus simple. Tout ce qu’il faut, c’est un hôte distant sur lequel push un projet afin que d’autres puissent le voir ; je ne veux pas vraiment de PR ni d’Actions
    Une fonction de « release » pour téléverser des assets binaires compilés en local serait bienvenue. Pour les forks, les gens peuvent cloner le dépôt puis le republier comme nouveau projet

    • Est-ce qu’on ne pourrait pas résoudre une bonne partie de cela en désactivant les fonctions inutiles ? Je viens de regarder mon instance Forgejo : il y a des options, dépôt par dépôt, pour désactiver Code, Projects, Releases, Packages, Actions, Issues, PRs et Wikis
    • https://sr.ht/
    • Alors, on revient à cgit ?

  • L’idée selon laquelle on pourrait stocker les données de review dans un dépôt git comme le code lui-même est assez convaincante
    Il serait très facile d’implémenter cela en créant une branche par review avec un préfixe connu, mais l’espace de noms des branches par défaut deviendrait vite encombré. On pourrait le séparer de l’espace principal avec les git namespaces, ou bien avoir une branche spéciale comme .reviews qui ne contiendrait que les ID des commits de fin de chaque branche de review. Si quelqu’un s’y intéressait assez pour produire une spécification et une implémentation réellement utilisable, peut-être que l’adoption commencerait. Si GitHub et les autres forges n’ont pas choisi cette voie, c’est probablement parce que garder les métadonnées de review enfermées dans leur propre écosystème fait partie de la valeur de leur plateforme. Si n’importe qui peut reviewer le code d’autrui avec les outils locaux de son choix, cela réduit le verrouillage fournisseur. Cela dit, il peut aussi y avoir d’autres raisons de vouloir stocker les métadonnées de review dans un autre dépôt, par exemple le contrôle d’accès ou les reviews entre dépôts

  • J’aime beaucoup le workflow Gerrit qui consiste à reviewer les diffs plutôt que des PR. Mais comparé à gitea, il manque les autres fonctionnalités qu’on attend désormais d’un hébergement git — issues, planification de projet, etc. — ce qui semble difficile à vendre à beaucoup de gens
    Ce serait bien d’avoir une bonne plateforme de review de diffs comme Phabricator, dommage que cela manque

    • Mais alors pourquoi Gitea ne l’ajoute-t-il pas ? Tout le reste est déjà là ; je ne comprends pas pourquoi ces forges restent toujours des clones de GitHub au lieu d’aller plus loin

  • Je pense qu’il faudrait utiliser RFC2822 comme format de base pour stocker tous les messages — PR, commentaires de review, issues, etc. — puis les habiller en CommonMark à l’affichage
    Toutes les métadonnées iraient dans les en-têtes, et on pourrait relier les messages entre eux avec les en-têtes Message-ID/In-Reply-To/References. Avec un format aussi bien défini, on peut choisir librement comment stocker et transporter tous les messages : dans un dépôt git, par e-mail, ou autrement si cela convient mieux. Pour la code review, je trouve personnellement que Gerrit est bien meilleur que GitHub et consorts. Pour la CI, j’aimerais la garder autant que possible à l’extérieur, avec seulement des hooks pour lancer les pipelines, afficher les résultats et décider si la fusion est autorisée

    • Je pense que l’un des attraits de GitHub est justement d’intégrer code review, exploration du code, suivi des tickets et CI
      Il n’excelle pas vraiment dans ces quatre domaines, mais il les assemble bien. Je suis d’accord pour dire que Gerrit a un meilleur modèle de code review, mais sans les trois autres briques, on n’a pas un produit complet. Même à l’époque où j’utilisais Gerrit tous les jours chez Google, la faible intégration entre recherche de code, code review et CI me frustrait. Les outils internes de Google comme Google3/Critique/Forge reliaient tout cela bien mieux

  • Je viens de penser à un avantage des workflows basés sur l’e-mail. Si on commence à consulter ses e-mails, c’est généralement qu’on est dans le bon état d’esprit pour cela, et dans cet état on s’attend à ne pas avoir d’autres distractions, donc on est plus concentré
    Le problème des notifications, c’est qu’elles donnent envie de les balayer dès qu’elles apparaissent. Mais rien ne garantit qu’on ait, à cet instant précis, l’énergie nécessaire pour les traiter. La plupart des systèmes de notifications du web ressemblent à des tentatives maladroites d’imiter ce que les clients e-mail avaient déjà réussi il y a des décennies. Peut-être qu’au fond, les anciens avaient vraiment raison d’utiliser l’e-mail

    • Un e-mail est aussi une notification ; peux-tu expliquer plus clairement comment on peut être dans le bon état d’esprit au moment où il arrive ?

  • Quand Microsoft a absorbé GitHub, beaucoup de gens étaient déjà agacés. Mais en pratique, les alternatives étaient souvent mauvaises. Sourceforge rend la création d’issues interminablement pénible, GitLab est meilleur que Sourceforge mais je déteste quand même y créer des issues, et Codeberg semble avoir récemment changé d’interface tout en restant assez peu pratique
    Ce que GitHub a bien fait au départ, c’est l’UI et le fait de se concentrer sur les personnes qui utilisent GitHub pour rendre les choses faciles, ou plus faciles. Il n’a pas tout bien fait pour autant ; par exemple, le support des wikis me paraît horrible. C’est tellement mauvais que je n’utilise presque jamais les wikis. Le vrai gros problème, à mon avis, ce sont les intérêts commerciaux, autrement dit les intérêts privés. Microsoft n’est qu’un exemple, mais c’est un problème présent sur presque tous les sites similaires. J’ai déjà pris comme exemple la discussion d’une issue liée à l’utilitaire de la backdoor xz, et j’y avais moi-même participé ; le lendemain, Microsoft avait tout supprimé. Que ce soit Microsoft ou le propriétaire du dépôt n’a pas vraiment d’importance. Le problème, c’est qu’une personne peut censurer trop facilement des informations potentiellement utiles. Cette discussion d’issue était utile et elle a été censurée. Si je me souviens bien, toutes les informations n’avaient pas été restaurées ensuite. Quelqu’un en a peut-être fait un miroir, mais je n’ai pas vu de lien. Cela montre à quel point le contrôle descendant peut être nuisible. Franchement, à quel point peut-on faire confiance à Microsoft ? Il nous faut quelque chose de décentralisé, stable, fiable, avec une bonne UI par défaut, et un workflow simple — ou au moins bon. Il faut aussi éviter qu’un acteur privé puisse prendre tout le monde en otage. Je n’ai absolument aucune idée de la manière de résoudre cela, et il faudra peut-être plusieurs approches en parallèle. Le web a changé, et j’ai le sentiment que les intérêts privés des très grandes entreprises ont rendu les choses bien pires au cours des 10 à 15 dernières années. Il faut que ça change

    • Le problème, c’est que faire tourner un produit SaaS coûte cher
      Les grandes entreprises peuvent absorber ce coût, mais même un grand nombre de développeurs avec de petits budgets n’ont pas les moyens de financer la même chose. Donc tout projet commercial finit inévitablement par aller dans une direction qui sert davantage les intérêts des grandes entreprises que ceux de la personne moyenne