Revisar os patches do git por e-mail sem sair do Thunderbird: um fluxo old-school ainda vivo

Korben traz à tona um fluxo de trabalho que muitos desenvolvedores jovens desconhecem completamente: a revisão de *patches* por e-mail, no estilo do núcleo do Linux. Um projeto permite fazer isso sem nunca sair do Thunderbird — e é mais relevante do que se imagina.

Um caso concreto: contribuir para o núcleo Linux, git, Emacs

Para um desenvolvedor que só conheceu GitHub e GitLab, a pergunta pode parecer estranha: "por que diabos revisar código por email?". Resposta concreta: porque os projetos que estruturam grande parte da informática moderna — o núcleo Linux (LKML), o próprio git, Emacs, U-Boot, QEMU, Postgres (parcialmente), a maioria dos projetos BSD — NÃO usam uma forja web para receber contribuições. O fluxo histórico permanece:

1. O contribuidor executa git format-patch para transformar sua branch em uma série de arquivos .patch, um por commit.
2. Ele envia esses patches em uma lista de discussão pública com git send-email.
3. Os mantenedores e pares respondem inline no email: eles citam as linhas de código do patch com prefixo > e escrevem seus comentários logo abaixo. É uma revisão de código, mas em um cliente de email.
4. O contribuidor envia uma v2, v3, etc. Um mantenedor acaba integrando a série com git am.

Esse fluxo tem qualidades objetivas que a forja web não tem: arquivos públicos indexáveis (lore.kernel.org, marc.info), participação sem conta no GitHub, respeito ao princípio "escreva uma vez, leia muitas vezes".

A ferramenta que Korben expõe: thunderbird-patch-review

O conforto da revisão no GitHub — realce de sintaxe, comentários por linha, Approve/Request changes — criou uma geração que acha a revisão por email ilegível. Resultado: a barreira de entrada para contribuir com o kernel aumenta, mesmo que git send-email seja uma ferramenta antiga e testada.

Marc Coquand queria integrar sua equipe a esse fluxo mail-first sem impor ferramentas exóticas. Por isso, desenvolveu thunderbird-patch-review, uma extensão para Thunderbird: quando um email contendo uma série de patches chega, a extensão oferece um botão para abrir uma visualização de revisão confortável — coloração dos patches, navegação para o arquivo alvo, aplicação local do patch para teste, resposta inline com a convenção correta de citação. A ideia não é substituir o GitHub, mas poder participar dos projetos que não o usam sem sofrer.

Para encontrar o repositório e a versão atual, remete-se ao artigo de Korben (link na fonte), que aponta diretamente para o repositório de Marc Coquand — em vez de citar uma URL de memória.

Como isso se articula do lado das ferramentas

Para reconstituir o pipeline completo, fora da extensão do Thunderbird:

• Configurar o SMTP no git: git config sendemail.smtpServer <servidor>.
• Preparar uma série com carta de apresentação e threading correto: git format-patch -N HEAD~M com as opções cover-letter (dois traços seguidos de cover-letter) e thread (dois traços seguidos de thread).
• Enviar a série: git send-email com as opções to=list@vger.kernel.org e cc=maintainer@example.org (cada uma prefixada por dois traços).
• Do lado da recepção: git am < email.mbox para aplicar uma série recebida.

Um fluxo inteiramente descentralizado, sem depender de terceiros. A documentação de referência é git send-email(1) no git-scm.com.

Para lembrar

• O fluxo por email não está morto nem é marginal: é o do kernel, do git, do Emacs, dos BSD.
• thunderbird-patch-review de Marc Coquand permite que um dev acostumado ao GitHub contribua sem mudar completamente de postura.
• Para testar: configurar uma conta SMTP de saída, tentar git send-email em uma contribuição trivial (por exemplo, um erro de digitação na documentação do kernel; a LKML é surpreendentemente acolhedora para os primeiros patches limpos).
• Bônus filosófico: também é um exercício útil de letramento em git — entender que o patch por email e o commit do git são quase o mesmo objeto, o que esclarece muitos comportamentos do git.