Reviewer Git-Patches per E-Mail ohne Thunderbird zu verlassen: ein Old-School-Workflow, der noch lebt

Korben stellt einen Arbeitsablauf in den Vordergrund, den viele junge Entwickler völlig ignorieren: die Überprüfung von Patches per E-Mail, im Stil des Linux-Kernels. Ein Projekt ermöglicht dies, ohne Thunderbird jemals zu verlassen - und es ist relevanter, als man denkt.

Ein konkreter Fall: Beitrag zum Linux-Kernel, zu git, zu Emacs

Für einen Entwickler, der nur GitHub und GitLab kennt, mag die Frage seltsam erscheinen: „Warum zum Teufel Code per E-Mail überprüfen?“ Konkrete Antwort: weil die Projekte, die einen großen Teil der modernen Informatik strukturieren - der Linux-Kernel (LKML), git selbst, Emacs, U-Boot, QEMU, Postgres (teilweise), die Mehrheit der BSD-Projekte - keine Web-Forge zur Entgegennahme von Beiträgen verwenden. Der historische Workflow bleibt:

1. Der Beitragende führt git format-patch aus, um seinen Branch in eine Reihe von .patch-Dateien umzuwandeln, eine pro Commit.
2. Er sendet diese Patches an eine öffentliche Mailingliste mit git send-email.
3. Die Wartungsverantwortlichen und Kollegen antworten inline in der E-Mail: Sie zitieren die Codezeilen des Patches mit dem Präfix > und schreiben ihren Kommentar direkt darunter. Es handelt sich um eine Code-Rezension, aber in einem E-Mail-Client.
4. Der Beitragende sendet eine v2, v3 usw. Ein Wartungsverantwortlicher integriert schließlich die Serie mit git am.

Dieser Fluss hat objektive Qualitäten, die die Web-Forge nicht hat: öffentlich durchsuchbare Archive (lore.kernel.org, marc.info), Teilnahme ohne GitHub-Konto, Einhaltung des Prinzips „Schreib es einmal, lies es viele Male“.

Das von Korben vorgestellte Tool: thunderbird-patch-review

Der Komfort der GitHub-Rezension - Syntax-Hervorhebung, Kommentare pro Zeile, Approve/Request changes - hat eine Generation hervorgebracht, die die E-Mail-Rezension unleserlich findet. Ergebnis: Die Einstiegshürde für Kernel-Beiträge steigt, obwohl git send-email ein bewährtes altes Tool ist.

Marc Coquand wollte sein Team in diesen mail-first-Workflow einbinden, ohne exotische Werkzeuge aufzuzwingen. Er hat daher thunderbird-patch-review entwickelt, ein Add-on für Thunderbird: Wenn eine E-Mail mit einer Reihe von Patches eintrifft, schlägt das Add-on einen Button vor, um eine komfortable Review-Ansicht zu öffnen - Farbgebung der Patches, Sprünge zum Zieldatei, lokale Anwendung des Patches zum Testen, inline-Antwort mit der richtigen Zitierkonvention. Die Idee ist nicht, GitHub zu ersetzen, sondern an Projekten teilnehmen zu können, die es nicht verwenden, ohne zu leiden.

Um das Repo und die aktuelle Version zu finden, wird auf den Artikel von Korben (Link in der Quelle) verwiesen, der direkt auf das Depot von Marc Coquand verweist - anstatt eine URL aus dem Gedächtnis zu zitieren.

Wie es sich auf der Werkzeugseite verhält

Um die vollständige Pipeline außerhalb der Thunderbird-Erweiterung wiederherzustellen:

• Konfigurieren Sie Ihren SMTP in git: git config sendemail.smtpServer <server>.
• Bereiten Sie eine Serie mit korrektem Cover Letter und Threading vor: git format-patch -N HEAD~M mit den Optionen cover-letter (zwei Bindestriche gefolgt von cover-letter) und thread (zwei Bindestriche gefolgt von thread).
• Senden Sie die Serie: git send-email mit den Optionen to=list@vger.kernel.org und cc=maintainer@example.org (jede mit zwei Bindestrichen vorangestellt).
• Auf Empfängerseite: git am < email.mbox um eine empfangene Serie anzuwenden.

Ein vollständig dezentralisierter Fluss, ohne Abhängigkeit von einem Dritten. Die Referenzdokumentation ist git send-email(1) auf git-scm.com.

Wichtige Punkte

• Der E-Mail-Workflow ist weder tot noch marginal: Es ist der des Kernels, von git, von Emacs, der BSD.
• thunderbird-patch-review von Marc Coquand ermöglicht es einem Entwickler, der an GitHub gewöhnt ist, beizutragen, ohne seine Haltung komplett zu ändern.
• Zum Testen: Konfigurieren Sie ein SMTP-Konto, versuchen Sie git send-email an einem trivialen Beitrag (z.B. ein Tippfehler in der Kernel-Dokumentation, die LKML ist überraschend gastfreundlich für die ersten sauberen Patches).
• Philosophischer Bonus: Es ist auch eine nützliche Übung in Git-Literatur - zu verstehen, dass der E-Mail-Patch und der Git-Commit fast dasselbe Objekt sind, was viele Verhaltensweisen von Git aufklärt.