xref: /linux/Documentation/translations/pt_BR/process/1.Intro.rst (revision 0fc8f6200d2313278fbf4539bbab74677c685531)

.. 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.