A abertura do ciclo do Linux 6.18 trouxe um assunto incômodo para a superfície: a fricção entre práticas de formatação automatizadas do ecossistema Rust e o fluxo de integração do kernel. Em mensagens na LKML datadas de 2 de outubro, Linus Torvalds reclamou do rustfmt, a ferramenta oficial de formatação de código do Rust, e da forma como um pull request do subsistema DRM foi preparado e enviado, com ênfase em formatação de texto/indentação e na organização de use imports em arquivos Rust.
O pano de fundo
No pull do DRM para o 6.18-rc1, houve adições de código em Rust para drivers gráficos. Ao revisar, Torvalds apontou que a hierarquia de tópicos do changelog chegou “achatada”, sem as indentações que comunicavam subáreas distintas, por exemplo, “Alloc”, “DMA/Scatterlist”, “DRM” e “Rust”. Para ele, esse achatamento torna a leitura “um amontoado aleatório”, dificultando avaliar rapidamente o que mudou em cada parte. A crítica veio com ironia, questionando qual editor de texto teria “quebrado” a formatação.
Na parte técnica, a discussão ficou mais interessante. Ao resolver um conflito de merge, Torvalds preferiu expandir use imports para múltiplas linhas, um padrão comum em bases com grande rotatividade: cada item em sua própria linha facilita adicionar/remover entradas depois e reduz conflitos futuros. Porém, ao rodar a verificação de formatação, o processo apontou que o código deveria ser “compactado” (vários itens em uma mesma linha), o que, na visão de Linus, é pior para manutenção. No fim, ele ignorou a sugestão automatizada e pediu uma “solução sensata”.
Miguel Ojeda, mantenedor do Rust-for-Linux, respondeu que o rustfmt tem opções de configuração para controlar a disposição de imports, como imports_layout, imports_granularity e group_imports, mas que ainda são instáveis e disponíveis apenas no Nightly, o que complica adotá-las no kernel. Ele também esclareceu que a intenção era que, após resolver conflitos, fosse executado o formatador automático (padrão do projeto), e não o “checker” usado em CI, mantendo a árvore consistentemente formatada. Dessa forma, Ojeda proativamente se dispôs a discutir com o upstream do Rust um ajuste que atenda às necessidades do kernel.
O pull do DRM também rendeu um choque de metodologias sobre formatação do texto do pull request. Dave Airlie, mantenedor do DRM, explicou que muitas vezes achata a indentação de listas para uniformizar a apresentação, dado o volume de contribuições heterogêneas que recebe. Torvalds contrapôs com números: entre as versões 6.16 e 6.17, fez 441 merges, quase dez vezes mais do que os 48 pulls integrados por Airlie no mesmo recorte, e mesmo assim “gasta o tempo para fazer do jeito certo”, defendendo que a legibilidade e a hierarquia visual no changelog ajudam na revisão técnica.
No curto prazo, o caminho mais pragmático parece ser um acordo de estilo específico para imports Rust no kernel, ainda que “menos bonito” para alguns, desde que reduza conflitos e passe no formatador usado nas CIs. A médio prazo, há espaço para a comunidade Rust alcançar um padrão de formatação que atenda melhor a cenários de grande escala e merge intenso, algo que interessa não só ao kernel, mas a qualquer repositório com muitos autores. Enquanto isso, vale um lembrete da “escola do Linux”: a automatização não pode atrapalhar a manutenção. Quando heurísticas de ferramentas começam a piorar diffs, gerar retrabalho e ocultar a intenção do patch, é sinal de que o processo precisa mudar, não o inverso.Fique por dentro das principais novidades da semana sobre tenologia e Linux: receba nossa newsletter!
