- L’objectif est de créer l’outil de collaboration git le plus simple possible
- Rendre l’exécution d’un serveur git auto-hébergé aussi simple que celle d’un serveur SSH, sans sacrifier le temps et l’énergie des collaborateurs externes
- Combiner les listes de diffusion et le workflow de pull request
- L’idée est de créer un outil de collaboration aussi simple que la génération de patchs, mais avec la facilité d’usage des pull requests
- Il ne s’agit pas de créer un autre dépôt de code, mais une solution git auto-hébergée extrêmement simple pour collaborer avec des contributeurs externes
Ce qu’il faut
- Ce dont le propriétaire du code a besoin pour faire tourner un serveur git :
- Ce dont les contributeurs externes ont besoin :
- une paire de clés SSH
- un client SSH
Les problèmes actuels
- L’email est excellent comme système distribué pour envoyer et recevoir des changements sur un dépôt git (séries de patchs), mais intégrer de nouveaux utilisateurs à une liste de diffusion, configurer correctement leur client mail, puis leur faire soumettre une contribution suffit à décourager beaucoup de développeurs
- Comme la collaboration s’appuie sur le protocole email, l’ensemble des fonctionnalités est limité. Par exemple, on ne peut pas modifier un email, chacun utilise un client différent, et ces clients ont des limitations différentes concernant les emails en texte brut et le téléchargement des patchs
- Les pull requests GitHub sont faciles à utiliser, modifier et gérer, mais elles ont l’inconvénient d’obliger les utilisateurs à rester dans le site de GitHub pour effectuer une revue de code
- C’est pratique pour des changements rapides, mais dès qu’on commence à lire du code dans un navigateur web, les inconvénients deviennent importants. À partir d’un certain point, il est plus pertinent de revoir le code dans son environnement de développement local ou dans un IDE
- Il existe des outils et des plugins pour revoir des PR dans un IDE, mais leur mise en place demande un effort énorme
- De plus, les solutions auto-hébergées qui imitent les pull requests nécessitent beaucoup d’infrastructure pour être administrées : base de données, site web connecté à git, administration, services, etc.
- Un autre point de friction majeur est que les utilisateurs externes doivent d’abord créer un compte et se connecter avant de pouvoir soumettre des changements de code. Cela ajoute une friction importante, à la fois pour les contributeurs externes et pour les propriétaires du code qui doivent provisionner l’infrastructure
- Il faut aussi souvent forker le dépôt avant de pouvoir soumettre une PR. Ensuite, on ne contribue plus jamais et le fork reste pour toujours. Cela paraît absurde
Présentation de Patch Request (PR)
- L’objectif est de créer un « serveur » git auto-hébergé permettant d’envoyer et de recevoir des patchs sans les tracas de la configuration email ni les limitations imposées par le protocole email
- L’objectif est aussi que le workflow principal tourne autour de l’environnement de développement local. GitHub apporte l’IDE dans le navigateur pour accompagner ce workflow, mais ici l’idée est d’inverser cette logique en faisant de la revue de code dans l’environnement local un citoyen de première classe
- Cela se situe à mi-chemin entre le workflow de pull request de GitHub et l’envoi/réception de patchs par email
- L’idée de base est d’utiliser une application SSH pour gérer la majorité des interactions entre les contributeurs et les propriétaires de projet. Tout peut se faire dans le terminal, de manière ergonomique et complète
- Les notifications passent par RSS et chaque changement d’état déclenche la génération d’actifs web statiques, de sorte que l’ensemble peut être hébergé sur un simple serveur web de fichiers
Workflow format-patch
- Ici, l’outil de collaboration fondamental est format-patch
- Que l’on soumette des changements de code ou qu’on les relise, tout se passe dans le code
- Le contributeur comme le propriétaire créent de nouveaux commits et génèrent des patchs les uns au-dessus des autres
- Cela évite d’avoir besoin d’un visualiseur web où un relecteur peut « commenter » une ligne d’un bloc de code. Pas nécessaire. Il suffit d’appliquer le patch du contributeur, d’écrire des commentaires ou des modifications de code, de générer un nouveau patch, puis d’envoyer le patch au serveur git comme « revue »
- Ce flux fonctionne exactement de la même manière même lorsque deux utilisateurs collaborent sur une série de changements
- Cela résout aussi le problème des multiples séries de patchs envoyées pour un même changement de code. Il y a une seule Patch Request centrale où se déroulent tous les changements et toute la collaboration
- On pourrait peut-être trouver un moyen d’exploiter git note pour gérer les revues/commentaires, mais honnêtement cette solution paraît brutale et au-delà du niveau de confort de la plupart des utilisateurs de git
- Il suffit d’envoyer la revue sous forme de code et d’annoter le code dans le langage de programmation utilisé
- C’est au contributeur de « traiter » ces annotations et de les supprimer dans le patch suivant
- Fonction imposée pour traiter tous les commentaires : s’il reste des commentaires non traités dans le code, le patch ne sera pas fusionné. Impossible de les ignorer, sinon ils risqueraient de remonter en amont par erreur
Fonctionnement de Patch Request
- Patch Request (PR) est la manière la plus simple de soumettre, revoir et accepter des changements sur un dépôt git. Voici comment cela fonctionne :
- un contributeur externe clone le dépôt (
git-clone)
- un contributeur externe modifie le code (
git-add & git-commit)
- un contributeur externe génère un patch (
git-format-patch)
- un contributeur externe soumet une PR au serveur SSH
- le propriétaire reçoit une notification RSS pour la nouvelle PR
- le propriétaire applique le patch en local depuis le serveur SSH (
git-am)
- le propriétaire écrit ses suggestions dans le code (
git-add & git-commit)
- le propriétaire envoie le patch au serveur SSH pour soumettre la revue (
git-format-patch)
- le contributeur externe reçoit une notification RSS pour la revue de la PR
- le contributeur externe réapplique le patch (
git-am)
- le contributeur externe relit et supprime les annotations dans le code
- le contributeur externe soumet un autre patch (
git-format-patch)
- le propriétaire applique le patch en local (
git-am)
- le propriétaire marque la PR comme approuvée et pousse le code sur
main (git-push)
1 commentaires
On dirait un nouvel ajout à Pico.sh - une collection open source permettant de gérer des services web entièrement via SSH.
Jusqu’à présent, on y trouvait notamment les éléments suivants :