Introdução¶
Sumário¶
O restante desta seção cobre o processo de desenvolvimento do kernel e os tipos de frustração que os desenvolvedores e empresas podem encontrar pelo caminho. Existem diversas razões que justificam a recomendação para que seja feito o merge do código do kernel ao kernel principal (“mainline”), como disponibilidade automática aos usuários, suporte da comunidade em diversas formas, e a oportunidade de influenciar a direção do desenvolvimento do kernel. Contribuições ao kernel Linux obrigatoriamente devem estar disponíveis sob uma licença compatível com a GPL.
How the development process works apresenta o processo de desenvolvimento, o ciclo de lançamento, e a mecânica da janela de merge. As várias fases no desenvolvimento de patch, revisão, e ciclo de merge são explicadas. Algumas ferramentas e listas de e-mail são discutidas. Desenvolvedores que queiram começar a desenvolver o kernel são encorajados a buscar e corrigir bugs como exercício inicial.
Early-stage planning cobre os primeiros passos do processo de desenvolvimento, com ênfase no envolvimento da comunidade de desenvolvedores o mais cedo possível.
Getting the code right é sobre o processo de codificação; muitas armadilhas já encontradas por outros desenvolvedores são discutidas. Alguns requisitos para patches são explicados, e é feita uma introdução para algumas ferramentas que podem ajudar a garantir que os patches de kernel estão corretos.
Posting patches fala sobre o processo de envio de patches para revisão. Para serem levados em consideração pela comunidade desenvolvedora, os patches devem estar devidamente formatados e descritos, assim como devem estar no lugar correto. Seguir os conselhos dessa seção pode ajudar na recepção positiva do seu trabalho.
Followthrough cobre o que acontece após o envio dos patches; o trabalho ainda está longe de estar concluído. Trabalhar com os revisores é parte crucial do processo de desenvolvimento; essa seção oferece dicas de como evitar problemas nesse estágio importante. Desenvolvedores são alertados a não presumir que o trabalho acabou após o merge do patch no “mainline”.
Advanced topics introduz dois tópicos mais “avançados”: gerenciamento de patches com git e revisão de patches por outros.
For more information conclui o documento com indicações de fontes com mais informações sobre o desenvolvimento do kernel.
Sobre este documento¶
O kernel Linux, com mais de 8 milhões de linhas de código e bem mais de 1000 contribuintes a cada lançamento (“release”), é um dos maiores e mais ativos projetos de software livre em existência. Desde seu modesto início em 1991, este kernel evoluiu para se tornar um dos melhores componentes de sistemas operacionais, rodando em pequenos players de música digital, PCs de mesa, os maiores supercomputadores em existência, e todos os outros tipos de sistema entre eles. É robusto, eficiente, e uma solução escalável para quase toda situação.
O crescimento do Linux trouxe o aumento no número de desenvolvedores (e empresas) desejando participar no seu desenvolvimento. Fabricantes de hardware querem garantir que o Linux suporte bem os seus produtos, tornando-os atrativos para usuários Linux. Fabricantes de sistemas embarcados, que usam o Linux como componente em um produto integrado, querem que o Linux seja tão capaz e adequado quanto possível para a tarefa em questão. Distribuidores de software que baseiam seus produtos em Linux têm claro interesse nas capacidades, performance, e confiabilidade do kernel Linux. É também comum que usuários finais queiram alterar o Linux para atender melhor suas necessidades.
Uma das características mais atrativas do Linux é sua facilidade de acesso a esses desenvolvedores; qualquer um com as habilidades necessárias pode melhorar o Linux e influenciar a direção do seu desenvolvimento. Produtos proprietários não conseguem oferecer esse tipo de abertura, que é característico do processo de software livre. O kernel é ainda mais acessível que a maioria dos outros projetos de software livre. Um ciclo típico de três meses de desenvolvimento do kernel pode envolver mais de 1000 desenvolvedores trabalhando para mais de 100 empresas (ou absolutamente nenhuma empresa).
Trabalhar com a comunidade de desenvolvimento do kernel não é uma tarefa árdua. Contudo, muitos colaboradores potenciais passaram por dificuldades ao tentar trabalhar no kernel. A comunidade evoluiu suas próprias formas de funcionamento que permitem operar de forma fluida (e produzir um produto de alta qualidade) em um ambiente em que milhares de linhas de código são alteradas todos os dias. Não é surpresa que o processo de desenvolvimento do kernel Linux seja muito diferente dos modelos de desenvolvimento proprietários.
O processo de desenvolvimento do kernel pode parecer estranho e intimidador para novos desenvolvedores, mas existem bons motivos e uma sólida experiência por trás disso. Um desenvolvedor que não entenda os caminhos próprios da comunidade kernel (ou pior, que tente menosprezá-los ou contorná-los) terá uma experiência frustrante pela frente. A comunidade de desenvolvimento ajuda aqueles que tentam aprender, mas gasta pouco tempo com aqueles que não escutam ou não ligam para o processo de desenvolvimento.
Espera-se que aqueles que leiam este documento sejam capazes de evitar essa experiência frustrante. Há muito material aqui, mas o esforço envolvido na sua leitura valerá a pena. A comunidade de desenvolvimento sempre necessita de desenvolvedores que ajudem a melhorar o kernel; o texto a seguir deve ajudar você - ou aqueles trabalhando para você - a se juntar à nossa comunidade.
Créditos¶
Esse documento foi escrito por Jonathan Corbet, corbet@lwn.net. Aprimorado pelos comentários de Johannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, e Jochen Voß.
Esse trabalho contou com o apoio da Linux Foundation; agradecimentos especiais para Amanda McPherson, que viu o valor desse esforço e fez tudo acontecer.
A importância de levar o código até o “mainline”¶
Algumas empresas e desenvolvedores ocasionalmente se perguntam por que devem se importar em aprender como trabalhar com a comunidade do kernel e ter seu código no “mainline” (o kernel mantido por Linus Torvalds e usado como base para os distribuidores Linux). No curto prazo, contribuir com o código pode parecer um gasto evitável; parece mais fácil apenas manter o seu código à parte e oferecer suporte direto aos usuários. A verdade é que manter código fora da árvore principal (“out-of-tree”) é uma falsa economia.
Para ilustrar os custos do código “out-of-tree”, aqui estão alguns aspectos relevantes do processo de desenvolvimento do kernel; a maioria será discutida com mais detalhes adiante neste documento. Considere:
Código integrado via merge ao “mainline” fica disponível para todos os usuários Linux. Estará automaticamente presente em todas as distribuições que o habilitarem. Não há necessidade de discos de armazenamento, downloads, ou as complicações de dar suporte a múltiplas versões de variadas distribuições; tudo simplesmente funciona, para o desenvolvedor e para o usuário. Incorporação ao “mainline” resolve um grande número de problemas de distribuição e suporte.
Enquanto desenvolvedores do kernel se esforçam para manter uma interface estável para o espaço do usuário, a API interna está em constante mudança. A ausência de uma interface interna estável é uma escolha deliberada de design; permite que sejam feitas melhorias fundamentais a qualquer tempo e resulta em código de qualidade superior. Uma consequência dessa política é que código “out-of-tree” precisa ser constantemente atualizado para que continue funcionando com novos kernels. Manter código “out-of-tree” requer significativo trabalho apenas para mantê-lo funcionando.
Por sua vez, código que está no “mainline” não precisa dessa manutenção, resultado de uma regra simples que exige que qualquer desenvolvedor que altere uma API, também conserte qualquer código que deixe de funcionar como resultado da alteração. Código que teve o merge realizado no “mainline” tem custo significativamente menor de manutenção.
Além disso, código que está no kernel será muitas vezes melhorado por outros desenvolvedores. Resultados surpreendentes podem surgir ao permitir que sua comunidade de usuários e clientes melhore seu produto.
Código do kernel está sujeito a revisão, tanto antes como depois do merge ao “mainline”. Independentemente das habilidades do desenvolvedor original, o processo de revisão invariavelmente encontra maneiras de evoluí-lo. Bugs severos e problemas de segurança são constantemente encontrados durante o processo de revisão. Isso é especialmente válido para código desenvolvido em ambiente isolado; tais códigos se beneficiam fortemente ao serem revistos por outros desenvolvedores. Código “out-of-tree” é código de baixa qualidade.
Participação no processo de desenvolvimento é a forma pela qual você pode influenciar a direção do desenvolvimento do kernel. Usuários que se queixam externamente são ouvidos, porém desenvolvedores ativos têm maior poder de articulação - e a habilidade de implementar mudanças que façam o kernel funcionar melhor para suas necessidades.
Quando o código é mantido à parte, sempre existe a possibilidade de que terceiros contribuam para uma implementação diferente de uma funcionalidade parecida. Se isso acontecer, ter seu código integrado via merge se tornará muito mais difícil - ao ponto de ser impossível. Você enfrentará duas alternativas desagradáveis, (1) manter uma funcionalidade “out-of-tree” indefinidamente ou (2) abandonar seu código e migrar seus usuários para a versão na árvore principal (“in-tree”).
Contribuição de código é a ação fundamental que faz todo o processo funcionar. Ao contribuir com seu código você pode adicionar nova funcionalidade ao kernel e proporcionar capacidades e exemplos que podem ser usados por outros desenvolvedores de kernel. Se você desenvolveu código para o Linux (ou está pensando em desenvolver), você claramente tem interesse na continuidade do sucesso dessa plataforma; contribuição de código é uma das melhores maneiras de garantir esse sucesso.
Todos os argumentos acima se aplicam a qualquer código “out-of-tree”, incluindo código distribuído de maneira proprietária, em formato exclusivamente binário. Existem fatores adicionais que devem ser levados em consideração antes de qualquer distribuição de código de kernel apenas em binário, incluindo:
As questões legais da distribuição de kernel proprietário são, no melhor dos casos, confusas; muitos detentores de direitos autorais do kernel acreditam que a maioria dos módulos binários são produtos derivados do kernel e que, como resultado, sua distribuição é uma violação da Licença Pública Geral GNU (“GNU General Public License”), que será tratada com mais profundidade abaixo. Este autor não é um advogado, e nada neste documento pode ser considerado aconselhamento jurídico. O verdadeiro status de módulos privados (“closed source”) só pode ser determinado judicialmente. Independentemente disso, a incerteza que cerca esses módulos existe.
Os módulos binários aumentam consideravelmente a dificuldade de depuração de problemas do kernel (“debugging”), a ponto de a maioria dos desenvolvedores de kernel sequer tentar. Portanto, a distribuição de módulos exclusivamente binários tornará mais difícil que os seus usuários recebam suporte.
O suporte também é mais difícil para distribuidores de módulos exclusivamente binários, que precisam fornecer uma versão do módulo para cada distribuição e cada versão do kernel que desejam suportar. Dezenas de versões de um único módulo podem ser necessárias para fornecer uma cobertura razoavelmente abrangente, e seus usuários terão que atualizar seu módulo separadamente sempre que atualizarem seu kernel.
Tudo o que foi dito acima sobre revisão de código se aplica em dobro ao código fechado. Como esse código não está disponível, ele não pode ter sido revisado pela comunidade e, sem dúvida, terá sérios problemas.
Os fabricantes de sistemas embarcados, em particular, podem ser tentados a ignorar grande parte do que foi dito nesta seção, acreditando que estão lançando um produto autossuficiente que usa uma versão congelada do kernel e não requer mais desenvolvimento após o lançamento. Esse argumento ignora o valor de uma revisão de código abrangente e o valor de permitir que seus usuários adicionem recursos ao seu produto. Mas esses produtos também têm uma vida comercial limitada, após a qual uma nova versão deve ser lançada. Nesse ponto, os fornecedores cujo código está no “mainline” e bem mantido estarão em uma posição muito melhor para preparar o novo produto para o mercado rapidamente.
Licenciamento¶
Código é submetido ao kernel do Linux sob diversas licenças, mas todo ele deve ser compatível com a versão 2 da Licença Pública Geral GNU (GPLv2), que é a licença que cobre a distribuição do kernel como um todo. Na prática, isso significa que todas as contribuições de código são cobertas pela GPLv2 (com, opcionalmente, uma linguagem que permita a distribuição sob versões posteriores da GPL) ou pela licença BSD de três cláusulas. Quaisquer contribuições que não sejam cobertas por uma licença compatível não serão aceitas no kernel.
A cessão de direitos autorais não é exigida (nem solicitada) para o código contribuído para o kernel. Todo o código incorporado ao kernel principal mantém sua titularidade original; como resultado, o kernel agora tem milhares de proprietários.
Uma implicação dessa estrutura de propriedade é que qualquer tentativa de alterar o licenciamento do kernel está fadada ao fracasso quase certo. Existem poucos cenários práticos em que o acordo de todos os detentores de direitos autorais poderia ser obtido (ou seu código removido do kernel). Portanto, em particular, não há perspectiva de migração para a versão 3 da GPL em um futuro próximo.
É imprescindível que todo o código contribuído para o kernel seja legitimamente software livre. Por esse motivo, código de contribuidores sem identidade conhecida ou contribuidores anônimos não será aceito. Todos os contribuidores são obrigados a “assinar” seu código, declarando que ele pode ser distribuído com o kernel sob a GPL. Código que não tenha sido licenciado como software livre por seu proprietário, ou que apresente risco de criar problemas relacionados a direitos autorais para o kernel (como código derivado de esforços de engenharia reversa sem as devidas salvaguardas) não pode ser contribuído.
Questões sobre direitos autorais são comuns em listas de discussão de desenvolvimento Linux. Normalmente, essas perguntas recebem muitas respostas, mas é importante lembrar que as pessoas que respondem a essas perguntas não são advogados e não podem fornecer aconselhamento jurídico. Se você tiver dúvidas jurídicas relacionadas ao código-fonte do Linux, não há substituto para conversar com um advogado especializado nessa área. Confiar em respostas obtidas em listas de discussão técnicas é arriscado.