Revisar los parches de git por correo sin salir de Thunderbird: un flujo clásico que sigue vivo

Korben saca a la luz un flujo de trabajo que muchos desarrolladores jóvenes ignoran por completo: la revisión de parches por correo electrónico, estilo núcleo Linux. Un proyecto permite hacerlo sin salir nunca de Thunderbird, y es más relevante de lo que parece.

Un caso concreto: contribuir al núcleo Linux, a git, a Emacs

Para un desarrollador que solo ha conocido GitHub y GitLab, la pregunta puede parecer extraña: «¿por qué demonios revisar código por email?». Respuesta concreta: porque los proyectos que estructuran gran parte de la informática moderna — el núcleo Linux (LKML), git mismo, Emacs, U-Boot, QEMU, Postgres (parcialmente), la mayoría de los proyectos BSD — no usan una forja web para recibir contribuciones. El flujo histórico sigue siendo:

1. El contribuyente ejecuta git format-patch para convertir su rama en una serie de archivos .patch, uno por commit.
2. Envía estos patches a una lista de correo pública con git send-email.
3. Los mantenedores y pares responden en línea en el email: citan las líneas de código del patch con el prefijo > y escriben su comentario justo debajo. Es revisión de código, pero en un cliente de email.
4. El contribuyente envía una v2, v3, etc. Un mantenedor termina integrando la serie con git am.

Este flujo tiene cualidades objetivas que la forja web no ofrece: archivos públicos indexables (lore.kernel.org, marc.info), participación sin cuenta de GitHub, respeto al principio «escríbelo una vez, léelo muchas veces».

La herramienta que Korben expone: thunderbird-patch-review

La comodidad de la revisión en GitHub — resaltado sintáctico, comentarios por línea, Approve/Request changes — ha creado una generación que encuentra la revisión por email ilegible. Resultado: la barrera de entrada para contribuir al kernel aumenta, aunque git send-email es una herramienta antigua y probada.

Marc Coquand quería incorporar a su equipo a este flujo mail-first sin imponer herramientas exóticas. Por eso desarrolló thunderbird-patch-review, una extensión para Thunderbird: cuando llega un email con una serie de patches, la extensión ofrece un botón para abrir una vista de revisión cómoda — coloración de patches, saltos al archivo objetivo, aplicación local del patch para probar, respuesta en línea con la convención correcta de citación. La idea no es reemplazar GitHub, sino poder participar en proyectos que no lo usan sin sufrir.

Para encontrar el repositorio y la versión actual, se remite al artículo de Korben (enlace en la fuente), que apunta directamente al repositorio de Marc Coquand — en lugar de citar una URL de memoria.

Cómo se articula el flujo en herramientas

Para reconstruir el pipeline completo, fuera de la extensión de Thunderbird:

• Configurar el SMTP en git: git config sendemail.smtpServer <servidor>.
• Preparar una serie con carta de presentación (cover letter) y threading correcto: git format-patch -N HEAD~M con las opciones cover-letter (dos guiones seguidos de cover-letter) y thread (dos guiones seguidos de thread).
• Enviar la serie: git send-email con las opciones to=list@vger.kernel.org y cc=maintainer@example.org (cada una con dos guiones como prefijo).
• Del lado de la recepción: git am < email.mbox para aplicar una serie recibida.

Un flujo completamente descentralizado, sin depender de un tercero. La documentación de referencia es git send-email(1) en git-scm.com.

Para recordar

• El flujo por email no está muerto ni es marginal: es el de kernel, git, Emacs, los BSD.
• thunderbird-patch-review de Marc Coquand permite a un desarrollador acostumbrado a GitHub contribuir sin cambiar por completo su postura.
• Para probar: configurar una cuenta SMTP saliente, intentar git send-email en una contribución trivial (por ejemplo, una errata en la documentación del kernel; la LKML es sorprendentemente acogedora con los primeros patches limpios).
• Bonus filosófico: también es un ejercicio útil de alfabetización en git — entender que el patch por email y el commit en git son casi el mismo objeto, lo que aclara muchos comportamientos de git.