Linux kernel newbies em português

Existe uma série de coisas que é preciso ter em mente quando estamos enviando alterações ao kernel. A principal coisa a se lembrar é que não importa o quanto ocupado você esteja, Andrew Morton e Linus Torvalds recebem modificações vindas de todo mundo, todo tempo, o que significa que eles estão bem mais ocupados que você.

As estratégias aqui descritas para suas alterações entrarem no kernel tendem a tornar as coisas muito mais fáceis pra os matenedores, o que significa que o seu código poderá entrar no kernel mais facilmente.

Não envie alterações enormes, quebre em pedaços

É tentador trabalhar em um projeto ou alteração por meses até que "esteja perfeita", e então você envia um patch enorme para a lista de discussão de desenvolvimento do kernel. No entanto, essa não é uma boa idéia por várias razões:

• Um projeto que contêm diversas alterações é eficientemente um projeto paralelo do kernel. Manter um projeto paralelo de desenvolvimento é um enorme esforço. Este esforço poderia ter sido aproveitado no projeto oficial do kernel e não em um projeto pararelo.
• Revisar um enorme patch toma muito tempo. A maioria dos revisores não tem todo esse tempo, e irão ignorar seu patch.
• Linus Torvalds e Andrew Morton são muito mais ocupados que a maioria dos revisores de patch, e normalmente nem se preocupam em revisar patches que ninguém tenha demonstrado interesse. neste contexto "interesse" normalmente está relacionado aos pontos mencionados abaixo.
• Quanto maior for o seu patch maior é a chance que contenha bugs e seja rejeitado.
• Mesmo que você tenha testado o seu código muito bem, ainda assim existe a possibilidade de ocorrer problemas em configurações estranhas de outras pessoas.
• Revisores de patches e mantenedores dos subsistemas do kernel não irão gostar de você caso você regularmente os incomode com patches difíceis e estranhos para revisão. Patches conhecidos como "bombas" podem estragar a sua reputação.
  Com sorte, a maioria dos problemas mencionados acima podem ser resolvidos enviando alterações em pedaços. Isto é especialmente fácil de se fazer caso suas modificações sejam independentes umas das outras e possam ser integradas separadamente.
• Uma alteração pequena e individualmente funcional ajuda muito. Geralmente um revisor deve conseguir revisar seu patch entre 5 e 10 minutos.
• Se o seu trabalho estiver separado em 8 patches, pequenos e fáceis de verificar, então existirá uma grande chance de que a maioria deles estejam corretos(você pode verifica-los facilmente) e serão aceitos.
• Aqueles que não estejam corretos, podem ser normalmente corrigidos com facilidade, pois, são pequenos.
• Tendo seus patches aceitos rapidamente, você poderá focar sua atenção em desenvolvimento, e não em manter um projeto paralelo do kernel.
• Revisores de patches e mantenedores de subsistemas gostarão de você por fazer a vidas deles mais fácil. Isto ajuda a construir a sua reputação na comunidade e deve tornar mais fácil a aceitação de alterações no futuro.
  A maneira de separar patches é por função, e não necessáriamente por arquivo. Cada patch deve conter uma modificação funcional que seja facilmente verificável, mesmo que você acabe alterando o mesmo arquivo em múltiplos patches.

Exemplo:

Digamos que você esteja trabalhando no driver "bar", para adicionar suporte ao dispositivo "foo". No entando, a maneira simples de se adicionar a funcionalidade tornaria o código uma verdadeira bagunça. A solução requer uma reorganização do código, após isso a sua funcionalidade irá ser integrada facilmente. A sua sequência de patches poderia se parecer com o seguinte:

Subject: [PATCH 0/3] adiciona suporte ao dispositivo foo no driver bar
Subject: [PATCH 1/3] suporte foo: adiciona abstração do tipo do dispositivo em bar_struct
Subject: [PATCH 2/3] suporte foo: limpa o código do driver bar
Subject: [PATCH 3/3] suporte foo: adiciona suporte a foo

Tradicionalmente o primeiro email não contém modificações, mas simplesmente explica o que os seus patches fazem e porque são necessários. Os outros emails são enviados como respostas ao primeiro email, dessa maneira as pessoas que não estejam interessadas em seus patches podem apenas fechar a thread em seus leitores de email.

Neste exemplo, os dois primeiros patches não conteriam a funcionalidade que você quer adicionar ao kernel. Tudo que eles fazem é modificar a base do código de maneira que torne mais fácil a integração da alteração. Os revisores e mantenedores gostam quando as pessoas deixam o código mais fácil para manutenção. Empilhar modificações em cima de modificações poderia em algum tempo tornar a base do código impossível de se manter, então a "maneira fácil" de adicionar funcionalidade nem sempre é "tão agradável assim".

Dicas sobre listas de discussão

• Cada patch deve conter apenas uma modificação lógica. Se o seu patch que renomea uma função toca em 20 arquivos, está tudo bem. Não precisar separá-los.
• Separar/quebrar o seu trabalho é difícil. É muito mais fácil manter suas modificações separadas durante o desenvolvimento.
• Os patches, que estão em resposta ao email inicial, devem ter o cabeçalho In-Reply-To: e/ou References:, que fazem referência ao email inicial
• Envie os seus patches em texto puro(ou plain text), no corpo do email. Isto torna fácil o trabalho dos revisores e os permite responder a seções do código.
• Teste o seu email. Primeiramente envie a série de patches para você mesmo, e se certifique que os patches enviados ainda aplicam ao kernel sem intervenções humanas. Algumas vezes os clientes de email modificam os patches, então tome cuidado.
• O sistema de gerenciamento de patch chamado quilt tem um script de envio de email que faz a coisa certa para envio de séries de patches. Quilt também ajuda a gerenciar séries de patches durante o desenvilvimento. Considere usar algo como quilt.
• Alguns clientes de email são realmente problemáticos. Especialmente o Thunderbird, ele não é adequado para envio de patches. Considere usar algo como quilt.

Retornos e Sugestões

Agora que você já tem o hábito de enviar seu código em pequenos patches, revisores poderão te dar um rápido retorno sobre os seus patches. Algumas vezes em uma hora. Agora que você tem a atenção deles, seria legal se você pudesse fazer algo a respeito dos comentários antes que eles movam para o outro código.

Você pode até não conseguir implementar tudo que foi comentado ou testar as modificações no código na mesma velocidade que os retornos irão chegar, não tem problema. No entanto, você provavelmente deveria deixar os revisores cientes de que você leu os comentários e que está fazendo algumas das modificações sugeridas. Melhor ainda se você puder comunicá-los antes que eles concentrem a atenção em outros pontos.

O benefício da dúvida

Muitas vezes os revisores de patches apontam bugs óbvios e melhorias. O tipo de modificação que você deveria ter feito, caso tivesse descoberto a falha. Com certeza você irá agir para corrigir o que foi mencionado no comentário.

No entanto, algumas vezes não estará claro se é melhor você continuar com o seu código original ou implementar a alternativa sugerida pelo revisor. Neste caso é melhor mudar o código para o que o revisor sugeriu.

Isto pode parecer contra-intuitivo. Mudar o código é um trabalho extra e tais mudanças podem introduzir novos bugs.

No entanto, implementar a idéia mencionada pelo revisor indica que você consegue trabalhar com a comunidade. Ainda mais importante, o revisor provavelmente dará suporte a suas idéias e então você terá mais uma pessoa para dar suporte a inclusão do seu patch. Por estar recebendo e acatando as sugestões da comunidade seu código será aceito mais facilmente.

Algumas vezes o revisor pode estar errado. Nestes casos a mehor coisa a ser feita é manter o sua alteração e explicar porque o funcionamento deve ser do jeito que você esta fazendo.

Libere sua alteração com rapidez, libere constantemente

Projetos de software podem levar um longo tempo e ter várias fases, incluindo o levantamento de requisitos, design, prototipação e testes. É fascinante trabalhar em um projeto "in-house" e então somente mostra-lo para a comunidade quando estiver pronto.

No entanto, a comunidade do kernel linux é muito maior que a sua organização, e é bem provável que tenha requisitos diferentes. Depois de um longo ano de projeto, você não irá querer voltar para a prancheta só porque você não conhecia os requisitos de uma pessoa.

A melhor estratégia é ir para a comunidade do kernel linux com o protótipo e design inicial.
Isso não somente te permite em receber um retorno e requisitos adicionais em um primeiro estágio, isto muitas vezes o coloca em contato com outras pessoas interessadas em resolver o mesmo problema. Você poderia inclusive terminar trabalhando junto com desenvolvedores de outras empresas, e trabalhar em uma implementação que seja muito melhor que qualquer coisa feita por você mesmo (sozinho).

É o tipo de solução que resolve um monte de problemas ao mesmo tempo.
É o tipo de solução que agrada Linus Torvalds e Andrew Mortom.
É o tipo de solução que na verdade será integrada no kernel, resolvendo seus problemas.

Escute

Alguns dos mais importantes revisores de patches na lista de discussão do kernel tem ganho a reputação de ser difícil de se trabalhar. Provavelmente porque eles usam seu tempo revisando código e não em sendo diplomáticos. Algumas vezes o retorno recebido por alguns patches é completamente rude. No entanto, isso não torna o retorno menos válido!

A razão pela qual as pessoas revisam seus patches e te dão um retorno é porque eles acreditam que você é capaz de agir e melhorar o seu código. Se você esta realmente interessado em melhorar o código, ouça ao retorno que você recebe na lista de discussão.

Mesmo que o retorno seja duro ou hostil ainda assim pode conter informações úteis. Se você se preocupa com o seu código, preste atenção e separe o trigo da soja.

Se você não entender alguma parte do retorno dado peça que seja melhor detalhado. O objetivo final é melhorar o seu código. Aprender alguma coisa nova durante o processo é um bônus para você.

Um bom comportamente seria sempre agradecer as pessoas que te derem um retorno amigável. Não se esqueça de sempre informá-los a respeito dos seus planos de atuação no que se refere aos retornos.

Leia os manuais

Verifique o check-list de envio de patches e outras documentações do kernel para ter certeza que você está enviando os seus patches da maneira correta. Se ater a esses pequenos detalhes não é somente fácil como também algo necessário.

Atenção: Esta é uma tradução livre do artigo escrito no wiki da comunidade kernelnewbies internacional MergingStrategy. Originalmente escrito por Rik van Riel.