docs: pt_BR: Translate 3.Early-stage.rst into Portuguese

Translate the documentation file '3.Early-stage.rst' into Portuguese.

This section addresses corporate kernel development constraints,
the balance between company secrecy and the open-loop approach,
and the use of NDAs or Linux Foundation programs to avoid
integration issues.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260601192346.192752-1-danielmaraboo@gmail.com>

Documentation/translations/pt_BR/process/3.Early-stage.rst

@@ -0,0 +1,233 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Planejamento em estágio inicial
+===============================
+
+Ao contemplar um projeto de desenvolvimento do kernel Linux, pode ser tentador
+dar um salto direto e começar a codificar. No entanto, como ocorre com qualquer
+projeto significativo, grande parte da base para o sucesso é melhor estabelecida
+antes que a primeira linha de código seja escrita. Um tempo gasto no planejamento
+e na comunicação iniciais pode economizar muito mais tempo mais adiante.
+
+
+Especificando o problema
+------------------------
+
+Como qualquer projeto de engenharia, um aprimoramento bem-sucedido do kernel
+começa com uma descrição clara do problema a ser resolvido. Em alguns casos,
+esta etapa é fácil: quando um driver é necessário para um componente de
+hardware específico, por exemplo. Em outros, no entanto, é tentador confundir o
+problema real com a solução proposta, e isso pode levar a dificuldades.
+
+Considere um exemplo: alguns anos atrás, desenvolvedores que trabalhavam com o
+áudio do Linux buscavam uma maneira de executar aplicativos sem interrupções
+(*dropouts*) ou outros artefatos causados por latência excessiva no sistema. A
+solução a que chegaram foi um módulo do kernel destinado a se conectar à
+estrutura do Linux Security Module (LSM); esse módulo poderia ser configurado
+para dar a aplicativos específicos acesso ao escalonador de tempo real. Esse
+módulo foi implementado e enviado para a lista de discussão linux-kernel, onde
+imediatamente encontrou problemas.
+
+Para os desenvolvedores de áudio, esse módulo de segurança era suficiente para
+resolver o problema imediato deles. Para a comunidade mais ampla do kernel, no
+entanto, ele foi visto como um uso indevido da estrutura LSM (que não tem a
+intenção de conceder privilégios a processos que eles de outra forma não
+teriam) e um risco para a estabilidade do sistema. As soluções preferidas da
+comunidade envolviam o acesso ao escalonamento de tempo real via mecanismo
+rlimit a curto prazo, e o trabalho contínuo de redução de latência a longo prazo.
+
+A comunidade de áudio, no entanto, não conseguia enxergar além da solução
+específica que havia implementado; eles não estavam dispostos a aceitar
+alternativas. O desacordo resultante deixou esses desenvolvedores sentindo-se
+desiludidos com todo o processo de desenvolvimento do kernel; um deles voltou
+para uma lista de áudio e postou isto:
+
+  "Existe um bom número de desenvolvedores muito bons no kernel Linux, mas eles
+  tendem a ser abafados por uma grande multidão de tolos arrogantes. Tentar
+  comunicar os requisitos dos usuários a essas pessoas é uma perda de tempo.
+  Eles são 'inteligentes' demais para ouvir os meros mortais."
+
+(https://lwn.net/Articles/131776/).
+
+A realidade da situação era diferente; os desenvolvedores do kernel estavam muito
+mais preocupados com a estabilidade do sistema, com a manutenção a longo prazo e
+em encontrar a solução correta para o problema do que com um módulo específico.
+A moral da história é focar no problema — e não em uma solução específica — e
+discuti-lo com a comunidade de desenvolvimento antes de investir na criação de
+um conjunto de códigos.
+
+Portanto, ao contemplar um projeto de desenvolvimento do kernel, deve-se
+obter respostas para um pequeno conjunto de perguntas:
+
+ - Qual é, exatamente, o problema que precisa ser resolvido?
+
+ - Quem são os usuários afetados por esse problema? Quais casos de uso a
+   solução deve abranger?
+
+ - De que forma o kernel deixa a desejar em resolver esse problema atualmente?
+
+Só então faz sentido começar a considerar possíveis soluções.
+
+
+Discussão inicial
+-----------------
+
+Ao planejar um projeto de desenvolvimento do kernel, faz todo o sentido realizar
+discussões com a comunidade antes de iniciar a implementação. A comunicação
+inicial pode economizar tempo e problemas de várias maneiras:number of ways:
+
+ - Pode muito bem ser que o problema já seja tratado pelo kernel de maneiras
+   que você não compreendeu. O kernel Linux é grande e possui uma série de
+   recursos e capacidades que não são imediatamente óbvios. Nem todas as
+   capacidades do kernel são documentadas tão bem quanto se gostaria, e é fácil
+   deixar passar algumas coisas. Este autor já viu a postagem de um driver
+   completo que duplicava um driver existente do qual o novo autor não tinha
+   conhecimento. Códigos que reinventam as rodas existentes não são apenas um
+   desperdício; eles também não serão aceitos no kernel principal (*mainline*).
+
+ - Pode haver elementos na solução proposta que não serão aceitáveis para a
+   integração no kernel principal . É melhor descobrir problemas
+   como este antes de escrever o código.
+
+ - É inteiramente possível que outros desenvolvedores já tenham pensado sobre
+   o problema; eles podem ter ideias para uma solução melhor e podem estar
+   dispostos a ajudar na criação dessa solução.
+
+Anos de experiência com a comunidade de desenvolvimento do kernel ensinaram uma
+lição clara: códigos do kernel que são projetados e desenvolvidos a portas
+fechadas invariavelmente apresentam problemas que só são revelados quando o
+código é lançado na comunidade. Às vezes, esses problemas são graves, exigindo
+meses ou anos de esforço antes que o código possa ser adequado aos padrões da
+comunidade do kernel. Alguns exemplos incluem:
+
+ - A pilha de rede Devicescape foi projetada e implementada para sistemas
+   monoprocessados. Ela não pôde ser integrada ao kernel principal (*mainline*)
+   até que fosse adaptada para sistemas multiprocessados. Ajustar retroativamente
+   mecanismos de travamento (*locking*) e afins em um código é uma tarefa difícil;
+   como resultado, a integração desse código (hoje chamado mac80211) foi atrasada
+   por mais de um ano.
+
+ - O sistema de arquivos Reiser4 incluía uma série de capacidades que, na
+   opinião dos desenvolvedores principais do kernel, deveriam ter sido
+   implementadas na camada de sistema de arquivos virtual (*Virtual Filesystem*
+   ou VFS). Ele também incluía recursos que não podiam ser facilmente
+   implementados sem expor o sistema a travamentos mútuos (*deadlocks*) causados
+   pelo usuário. A revelação tardia desses problemas — e a recusa em corrigir
+   alguns deles — fez com que o Reiser4 permanecesse fora do kernel principal
+   (*mainline*).
+
+ - O módulo de segurança AppArmor fazia uso de estruturas de dados internas
+   do sistema de arquivos virtual de maneiras que eram
+   consideradas inseguras e não confiáveis. Essa preocupação (entre outras)
+   manteve o AppArmor fora do kernel principal (*mainline*) por anos.
+
+In each of these cases, a great deal of pain and extra work could have been
+avoided with some early discussion with the kernel developers.
+
+
+Como encontrar os mantenedores?
+-------------------------------
+
+Quando os desenvolvedores decidem tornar seus planos públicos, a próxima
+pergunta será: por onde começamos? A resposta é encontrar a(s) lista(s) de
+discussão correta(s) e o mantenedor adequado. Para listas de discussão, a
+melhor abordagem é procurar no arquivo MAINTAINERS por um local relevante para
+postar. Se houver uma lista de subsistema adequada, postar nela costuma ser
+preferível a postar na linux-kernel; é mais provável que você alcance
+desenvolvedores com experiência no subsistema relevante e o ambiente pode ser
+mais acolhedor.
+
+Encontrar os mantenedores pode ser um pouco mais difícil. Novamente, o arquivo
+MAINTAINERS é o lugar para começar. No entanto, esse arquivo tende a não estar
+sempre atualizado, e nem todos os subsistemas estão representados ali. A
+pessoa listada no arquivo MAINTAINERS pode, na verdade, não ser quem está
+atuando nessa função atualmente. Portanto, quando houver dúvidas sobre quem
+contactar, um truque útil é usar o git (e o "git log" em particular) para ver
+quem está ativo no momento dentro do subsistema de interesse. Observe quem
+está escrevendo os patches e quem, se houver alguém, está anexando linhas
+"Signed-off-by" a esses patches. Essas são as pessoas que estarão em melhor
+posição para ajudar com um novo projeto de desenvolvimento.
+
+A tarefa de encontrar o mantenedor correto às vezes é desafiadora o suficiente
+para que os desenvolvedores do kernel tenham adicionado um script para facilitar
+o processo:
+
+::
+
+	.../scripts/get_maintainer.pl
+
+Este script retornará o(s) mantenedor(es) atual(is) para um determinado arquivo
+ou diretório quando fornecida a opção "-f". Se receber um patch na linha de
+comando, ele listará os mantenedores que provavelmente devem receber cópias do
+patch. Esta é a maneira preferencial (ao contrário da opção "-f") de obter a
+lista de pessoas para incluir em cópia (Cc) nos seus patches. Há uma série de
+opções que regulam o quão profundamente o get_maintainer.pl buscará por
+mantenedores; por favor, tenha cuidado ao usar as opções mais agressivas, pois
+você pode acabar incluindo desenvolvedores que não têm interesse real no código
+que você está modificando.
+
+Se tudo mais falhar, falar com Andrew Morton pode ser uma maneira eficaz de
+rastrear um mantenedor para um trecho específico de código.
+
+
+Quando postar?
+--------------
+
+Se possível, postar seus planos durante os estágios iniciais só pode
+ser útil. Descreva o problema que está sendo resolvido e quaisquer
+planos que tenham sido feitos sobre como a implementação será feita.
+Qualquer informação que você possa fornecer pode ajudar a comunidade de
+desenvolvimento a dar contribuições úteis sobre o projeto.
+
+Uma coisa desanimadora que pode acontecer neste estágio não é uma
+reação hostil, mas, em vez disso, pouca ou nenhuma reação. A triste
+verdade sobre o assunto é que (1) os desenvolvedores do kernel tendem a
+estar ocupados, (2) não há escassez de pessoas com planos grandiosos e
+pouco código (ou mesmo perspectiva de código) para apoiá-los, e (3)
+ninguém é obrigado a revisar ou comentar sobre ideias postadas por
+outros. Além disso, designs de alto nível frequentemente escondem
+problemas que só são revelados quando alguém realmente tenta
+implementar esses designs; por essa razão, os desenvolvedores do kernel
+preferem ver o código.
+
+Se uma postagem de pedido de comentários (RFC) render poucos
+comentários, não presuma que isso significa que não há interesse no
+projeto. Infelizmente, você também não pode presumir que não há
+problemas com sua ideia. A melhor coisa a fazer nesta situação é
+prosseguir, mantendo a comunidade informada à medida que avança.
+
+
+Obter a aprovação oficial
+-------------------------
+
+Se o seu trabalho estiver sendo realizado em um ambiente corporativo  como é o
+caso da maior parte do trabalho no kernel do Linux —, você deve, obviamente, ter
+a permissão de gerentes devidamente autorizados antes de poder publicar os
+planos ou o código da sua empresa em uma lista de discussão pública.
+A publicação de código que não tenha sido liberado para lançamento sob uma
+licença compatível com a GPL pode ser especialmente problemática; quanto mais
+cedo a gerência e a equipe jurídica de uma empresa puderem entrar em acordo
+sobre a publicação de um projeto de desenvolvimento do kernel, melhor será para
+todos os envolvidos.
+
+Alguns leitores podem estar pensando, neste ponto, que o seu trabalho no kernel
+se destina a dar suporte a um produto que ainda não tem uma existência oficialmente
+reconhecida. Revelar os planos de seu empregador em uma lista de discussão pública
+pode não ser uma opção viável. Em casos como esse, vale a pena considerar se o
+segredo é realmente necessário; muitas vezes não há uma real necessidade de manter
+os planos de desenvolvimento a portas fechadas.
+
+Dito isso, também existem casos em que uma empresa legitimamente não pode
+revelar seus planos logo no início do processo de desenvolvimento. Empresas com
+desenvolvedores de kernel experientes podem optar por prosseguir de maneira isolada
+(em "malha aberta"), partindo do pressuposto de que serão capazes de evitar problemas
+graves de integração mais tarde. Para empresas que não possuem esse tipo de expertise
+interna, a melhor opção costuma ser a contratação de um desenvolvedor externo para
+revisar os planos sob um acordo de confidencialidade (NDA). A Linux Foundation opera
+um programa de NDA projetado para ajudar nesse tipo de situação; mais informações
+podem ser encontradas em:
+
+    https://www.linuxfoundation.org/nda/
+
+Esse tipo de revisão costuma ser suficiente para evitar problemas graves mais
+tarde, sem a necessidade de uma divulgação pública do projeto.

Documentation/translations/pt_BR/process/development-process.rst

@@ -19,3 +19,4 @@ conhecimento profundo de programação de kernel para ser compreendida.
 
    1.Intro
    2.Process
+   3.Early-stage