[PATCH] docs: pt_BR: translate process/1.Intro.rst

[Daniel Castro <arantescastro@gmail.com>]

Add Brazilian Portuguese translation of the development process
introduction (Documentation/process/1.Intro.rst), covering the
executive summary, importance of mainline code, and licensing.

Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Daniel Castro <arantescastro@gmail.com>
---
 Documentation/translations/pt_BR/index.rst    |   1 +
 .../translations/pt_BR/process/1.Intro.rst    | 300 ++++++++++++++++++
 2 files changed, 301 insertions(+)
 create mode 100644 Documentation/translations/pt_BR/process/1.Intro.rst

diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
index de5c005f91d6..4f7fcc3c66fb 100644
--- a/Documentation/translations/pt_BR/index.rst
+++ b/Documentation/translations/pt_BR/index.rst
@@ -66,6 +66,7 @@ kernel e sobre como ver seu trabalho integrado.
 .. toctree::
    :maxdepth: 1
 
+   Introdução <process/1.Intro>
    Como começar <process/howto>
    Requisitos mínimos <process/changes>
    Manuais dos mantenedores <process/maintainer-handbooks>
diff --git a/Documentation/translations/pt_BR/process/1.Intro.rst b/Documentation/translations/pt_BR/process/1.Intro.rst
new file mode 100644
index 000000000000..e39470e9ce52
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/1.Intro.rst
@@ -0,0 +1,300 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _development_process_intro:
+
+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 propriedade 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.
-- 
2.53.0