O estopim foi mundano: um pull request no io_uring para trocar kvmalloc_array() por kvcalloc(). Na avaliação de Linus Torvalds, a mudança não corrigia nada de concreto — e o Link: trailer que deveria justificar o porquê da alteração levava apenas à mesma discussão já resumida no commit. Em bom “linusês”: tempo perdido.
“Stop this garbage already. Stop adding pointless Link arguments that waste people’s time.”
Para quem acompanha Linux kernel development, o recado não é contra links — é contra links que não agregam contexto. Quando um link não traz informação adicional (uma análise, um relatório de oops, um bug reproduzível, um fio de discussão com conclusões), ele vira ruído na revisão. Nesse caso específico, até a parte “técnica” reforçou a irritação: já existia __GFP_ZERO, então a troca parecia redundante — e o link não ajudou a explicar por que a mudança faria diferença.
O debate: quando um link agrega valor?
A discussão cresceu — e Linus esclareceu que gosta de links úteis. Ele apontou cenários em que o Link: faz sentido, como apontar para a cover letter de uma série de patches (o “quadro geral”) ou para um thread onde houve debate real. A ideia é simples: se alguém está lendo a mensagem de merge, provavelmente busca contexto amplo, não um eco do commit. Linus também sugeriu “desencorajar o uso automático e sem critério” e até flertou com heurísticas (quem sabe, com ajuda de IA) que só adicionem Link: quando houver discussão substancial no tópico.
Em linguagem de corredor: link é trilha de migalhas. Se leva ao mesmo lugar de onde você veio, pra quê?
O papel da automação — e do b4 — nessa história
Grande parte desses Link: trailers nasce de ferramentas que agilizam o fluxo do kernel — por exemplo, o b4, usado por mantenedores para buscar e aplicar patches a partir da lista. O b4, inclusive, tem flags que adicionam o Link: automaticamente com a URL do e-mail no lore e permitem configurar o formato do trailer (há projetos que preferem “Message-Id”). É poderoso — e, como toda automação, precisa de critério.
Do outro lado, a própria documentação do kernel reconhece cenários onde links ajudam, especialmente para referenciar uma versão anterior da série ou a cover letter. De novo: link como atalho para contexto, não como “enfeite” no rodapé do commit.
Por que isso importa para quem trabalha com Linux kernel development
No final do dia, o que está em jogo é produtividade de revisão — o trabalho que Linus descreve como “o principal dele”: transformar dezenas de milhares de mudanças por ciclo em lançamentos estáveis, no prazo. Links automáticos que não somam conteúdo são como “placas de trânsito” apontando para lugar nenhum: você lê, desacelera, e perde foco.
Se você contribui ou mantém subsistemas, aqui vai um checklist prático — curto, acionável e honesto:
- Use Link: só quando houver “informação extra”: relatório de crash, bug rastreável, benchmark, cover letter que explique a série, decisões do thread.
- Evite Link: para o próprio patch “espelho” no lore — isso duplica o que já está no commit e confunde quem busca por que a mudança existe.
- Prefira linkar o thread (ou a cover letter) quando houver discussão real — é onde estão as motivações, trade-offs e NAKs/Acks relevantes.
- Ajuste sua automação: se usa b4, avalie quando não adicionar Link: por padrão; considere
--add-linkapenas quando há valor, e conheça as opções de linkmask e message-id. - Resumo no commit continua rei: o commit deve ser autossuficiente para explicar o problema e a solução. O Link: é complemento — não muleta.
No fundo, a bronca é menos sobre estilo e mais sobre custo cognitivo. Em um projeto com o tamanho e a velocidade do Kernel Linux, cada distração escala. Se a automação não poupa tempo de quem revisa — ela atrapalha. E quando Linus diz isso em voz alta, a comunidade escuta.
