Gitメールでパッチをレビューする：Thunderbirdを離れずに、Old-Schoolなワークフローを生き返らせる

Korbenは、多くの若い開発者が完全に無視している作業フローを再び注目させます：メールによるパッチのレビュー、Linuxカーネルスタイルのものです。このプロジェクトは、Thunderbirdを離れることなくそれを行うことを可能にします - そして、それは思われているよりも関連性があります。

Un cas concret : contribuer au noyau Linux, à git, à Emacs

Pour un dev qui n'a connu que GitHub et GitLab, la question paraîtra étrange : « pourquoi diable réviser du code par email ? » Réponse concrète : parce que les projets qui structurent une bonne partie de l'informatique moderne - le noyau Linux (LKML), git lui-même, Emacs, U-Boot, QEMU, Postgres (partiellement), la majorité des projets BSD - n'utilisent PAS de forge web pour recevoir les contributions. Le workflow historique reste :

1. Le contributeur exécute git format-patch pour transformer sa branche en série de fichiers .patch, un par commit.
2. Il envoie ces patches sur une mailing list publique avec git send-email.
3. Les mainteneurs et pairs répondent inline dans le mail : ils citent les lignes de code du patch en préfixe > et écrivent leur commentaire juste dessous. C'est de la revue de code, mais dans un client mail.
4. Le contributeur envoie une v2, v3, etc. Un mainteneur finit par intégrer la série avec git am.

Ce flux a des qualités objectives que la forge web n'a pas : archives publiques indexables (lore.kernel.org, marc.info), participation sans compte GitHub, respect du principe « write it once, read it many times ».

L'outil que Korben expose : thunderbird-patch-review

Le confort de la revue GitHub - surlignage syntaxique, commentaires par ligne, Approve/Request changes - a créé une génération qui trouve la revue par mail illisible. Résultat : la barrière d'entrée à la contribution kernel monte, alors même que git send-email est un vieil outil éprouvé.

Marc Coquand avait envie d'embarquer son équipe dans ce workflow mail-first sans imposer d'outillage exotique. Il a donc développé thunderbird-patch-review, une extension pour Thunderbird : lorsqu'un mail contenant une série de patches arrive, l'extension propose un bouton pour ouvrir une vue de revue confortable - coloration des patches, sauts vers le fichier ciblé, application locale du patch pour tester, réponse inline avec la bonne convention de citation. L'idée n'est pas de remplacer GitHub, c'est de pouvoir participer aux projets qui ne l'utilisent pas sans souffrir.

Pour trouver le repo et la version courante, on renvoie à l'article de Korben (lien en source), qui pointe directement vers le dépôt de Marc Coquand - plutôt que de citer une URL de mémoire.

Comment ça s'articule côté outillage

Pour reconstituer le pipeline complet, en dehors de l'extension Thunderbird :

• Configurer son SMTP dans git : git config sendemail.smtpServer <serveur>.
• Préparer une série avec cover letter et threading corrects : git format-patch -N HEAD~M avec les options cover-letter (deux tirets suivis de cover-letter) et thread (deux tirets suivis de thread).
• Envoyer la série : git send-email avec les options to=list@vger.kernel.org et cc=maintainer@example.org (chacune préfixée de deux tirets).
• Côté réception : git am < email.mbox pour appliquer une série reçue.

Un flux entièrement décentralisé, sans dépendre d'un tiers. La doc de référence est git send-email(1) sur git-scm.com.

À retenir

• Le workflow email n'est ni mort ni marginal : c'est celui du kernel, de git, d'Emacs, des BSD.
• thunderbird-patch-review de Marc Coquand permet à un dev habitué à GitHub d'y contribuer sans changer complètement de posture.
• Pour tester : configurer un compte SMTP sortant, essayer git send-email sur une contribution triviale (typo dans la doc kernel par exemple, la LKML est étonnamment accueillante pour les premiers patches propres).
• Bonus philosophique : c'est aussi un exercice utile de littératie git - comprendre que le patch email et le commit git sont presque le même objet, ce qui éclaire beaucoup de comportements de git.