270 lines
16 KiB
ReStructuredText
270 lines
16 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
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.
|
|
|
|
:ref:`development_process` 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.
|
|
|
|
:ref:`development_early_stage` cobre os primeiros passos do processo de
|
|
desenvolvimento, com ênfase no envolvimento da comunidade de desenvolvedores o
|
|
mais cedo possível.
|
|
|
|
:ref:`development_coding` é 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.
|
|
|
|
:ref:`development_posting` 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.
|
|
|
|
:ref:`development_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".
|
|
|
|
:ref:`development_advancedtopics` introduz dois tópicos mais "avançados":
|
|
gerenciamento de patches com git e revisão de patches por outros.
|
|
|
|
:ref:`development_conclusion` 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.
|