Minha primeira contribuição para o kernel foi roubada

• O autor estava lidando com um problema de depuração em um projeto que incluía gdbserver e aplicações multithread executadas na arquitetura PowerPC32.
• O problema era que a conexão com o gdbserver era interrompida e já não era mais possível controlar a sessão de depuração.
• Após pesquisa e investigação, o autor encontrou uma thread de e-mails que apontava para o commit exato que causou esse problema.
• O autor passou 3 a 4 dias lendo descrições de commits relacionadas à arquitetura PowerPC e às mudanças em torno de task_struct, tentando descobrir se esse problema havia sido resolvido em versões posteriores do kernel.
• O autor usou várias ferramentas e técnicas, como mover a thread thread_struct, inspecionar o layout de task_struct com pahole e usar ftrace para descobrir quando as threads do processo depurado eram escalonadas.
• O autor descobriu que o problema poderia ser de corrupção de memória, já que a thread travada era escalonada apenas uma vez, ao contrário das outras.
• O autor implementou um módulo do kernel Linux para usar breakpoints de hardware no Linux e colocou um breakpoint de hardware no campo __state para descobrir quem estava escrevendo nele.
• O autor descobriu que o problema era um buffer overflow em ptrace_put_fpr (usado pela API POKEUSER), que sobrescrevia campos críticos de task_struct, como __state.
• Como esse problema poderia causar uma vulnerabilidade de segurança, o autor enviou um patch para a equipe de segurança do kernel Linux ([e-mail]) para corrigi-lo.
• Em vez de aceitar o patch do autor, o mantenedor de PowerPC, Michael Ellerman, implementou sua própria versão da correção.
• O autor sentiu que seu trabalho não foi devidamente reconhecido, ficou com a sensação de ter sido desvalorizado e irritado. Ele recebeu apenas a tag Reported-by.
• A primeira contribuição do autor para o kernel foi uma experiência cheia de frustração e desânimo, marcada por conversas com pessoas que aparentemente não acham importante que os outros recebam o devido reconhecimento pelo próprio trabalho.

[GN⁺]

Comentários do Hacker News

• Artigo sobre uma situação em que o patch do autor não foi totalmente aceito, mas o mantenedor usou a ideia para corrigir um problema de segurança
• Alguns comentários dizem que, mesmo que o patch completo não tenha sido aceito, o mantenedor deveria ter dado crédito ao autor
• Outros argumentam que o patch do mantenedor é melhor e mais eficiente, mas que ainda assim é preciso reconhecer que o autor identificou o problema e propôs uma solução
• Alguns comentários destacam que o kernel Linux não é uma recompensa e que o mantenedor tem o direito de escolher a melhor solução, ao mesmo tempo em que enfatizam a importância de dar crédito ao autor
• Menção à tag "Suggested-by" na documentação do kernel como forma de dar crédito a quem sugeriu a ideia do patch
• Alguns comentários dizem que isso é uma parte comum de contribuir para o kernel e que o principal objetivo é corrigir bugs, não receber crédito
• Comentários compartilham experiências de contribuições ignoradas ou não totalmente aceitas em projetos de código aberto, o que pode desestimular novas contribuições
• Comentários comparam o patch do autor e o do mantenedor, apontam as diferenças e sugerem que crédito deveria ter sido dado ao autor original
• A discussão também toca na importância de lidar com as contribuições de membros mais juniores da equipe de uma forma que incentive aprendizado e melhoria
• Comentários expressam confusão com a reação negativa, argumentando que reconhecimento importa e que adicionar um coautor é um gesto pequeno, mas significativo
• A discussão termina com comentários sobre a importância da diplomacia e de manter relações de longo prazo em projetos de código aberto