[PATCH] docs: pt_BR: translate process/2.Process.rst

[Daniel Castro <arantescastro@gmail.com>]

Add Brazilian Portuguese translation of the development process
document (Documentation/process/2.Process.rst), covering the
development cycle overview, patch lifecycle, subsystem trees,
staging trees, tools, mailing lists, and getting started with
kernel development.

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/2.Process.rst  | 514 ++++++++++++++++++
 2 files changed, 515 insertions(+)
 create mode 100644 Documentation/translations/pt_BR/process/2.Process.rst

diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
index 4f7fcc3c66fb..edf19ddf8916 100644
--- a/Documentation/translations/pt_BR/index.rst
+++ b/Documentation/translations/pt_BR/index.rst
@@ -69,4 +69,5 @@ kernel e sobre como ver seu trabalho integrado.
    Introdução <process/1.Intro>
    Como começar <process/howto>
    Requisitos mínimos <process/changes>
+   Como o processo de desenvolvimento funciona <process/2.Process>
    Manuais dos mantenedores <process/maintainer-handbooks>
diff --git a/Documentation/translations/pt_BR/process/2.Process.rst b/Documentation/translations/pt_BR/process/2.Process.rst
new file mode 100644
index 000000000000..6443e80f0ecd
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/2.Process.rst
@@ -0,0 +1,514 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Como o processo de desenvolvimento funciona
+===========================================
+
+O desenvolvimento do kernel Linux no início da década de 1990 era bastante
+informal, com um número relativamente pequeno de usuários e desenvolvedores
+envolvidos. Com uma base de usuários na casa dos milhões e cerca de 2.000
+desenvolvedores envolvidos ao longo de um ano, o kernel teve que desenvolver uma
+série de processos para manter o desenvolvimento fluindo sem problemas. Um
+sólido conhecimento de como o processo funciona é necessário para participar
+efetivamente dele.
+
+Visão geral
+-----------
+
+O kernel Linux utiliza um modelo de desenvolvimento contínuo ("rolling release")
+baseado em prazos flexíveis.  Uma nova versão principal do kernel (que
+chamaremos, por exemplo, de 9.x) [1]_ ocorre a cada dois ou três meses, trazendo
+novos recursos, alterações internas na API e muito mais. Uma versão típica pode
+conter cerca de 13.000 conjuntos de alterações, com mudanças em várias centenas
+de milhares de linhas de código.  Versões recentes, juntamente com suas datas,
+podem ser encontradas na `Wikipedia
+<https://en.wikipedia.org/wiki/Linux_kernel_version_history>`_.
+
+.. [1] Rigorosamente falando, o kernel Linux não utiliza o esquema de
+       versionamento semântico. Em vez disso, o par 9.x identifica a
+       versão principal como um número inteiro. Para cada versão, x é
+       incrementado, mas 9 é incrementado apenas se x for considerado
+       grande o suficiente (por exemplo, o Linux 5.0 é lançado após o
+       Linux 4.20).
+
+Segue-se um procedimento relativamente simples quanto à integração de
+patches para cada lançamento. No início de cada ciclo de desenvolvimento, a
+janela de fusão ("merge window") é considerada aberta. Nesse momento, o código
+que é considerado suficientemente estável (e que é aceito pela comunidade de
+desenvolvimento) é integrado ao kernel principal. A maior parte das
+alterações para
+um novo ciclo de desenvolvimento (e todas as principais alterações) será
+integrada durante esse período, a uma taxa próxima de 1.000 alterações
+("patches" ou "conjuntos de alterações") por dia.
+
+(Vale observar que as alterações integradas durante a
+janela de merge não surgem do nada; elas foram coletadas, testadas e
+preparadas com
+antecedência. O funcionamento desse processo será descrito em detalhes mais
+adiante).
+
+A janela de merge dura aproximadamente duas semanas. Ao final desse período, Linus
+Torvalds declarará que a janela está fechada e lançará o primeiro dos kernels
+"rc". Para o kernel que está destinado a ser o 9.x, por exemplo, o lançamento
+que ocorre ao final da janela de merge será chamado de 9.x-rc1. O lançamento
+-rc1 é
+o sinal de que o tempo para incorporar novos recursos passou e que o tempo para
+estabilizar o próximo kernel começou.
+
+Nas próximas seis a dez semanas, somente patches que corrijam problemas devem
+ser enviados para a versão principal ("mainline"). Ocasionalmente, uma mudança
+mais significativa será permitida, mas tais ocasiões são raras; desenvolvedores
+que tentam integrar novos recursos fora da janela de merge tendem a receber uma
+recepção pouco calorosa.  Como regra geral, se você perder a janela de merge para
+um determinado recurso, o melhor a fazer é esperar pelo próximo ciclo de
+desenvolvimento. (Uma exceção ocasional é feita para drivers para hardware
+anteriormente não suportado; se eles não alterarem nenhum código já
+presente na árvore ("in-tree"), não podem causar regressões e podem ser
+adicionados com segurança a qualquer momento).
+
+À medida que as correções são incorporadas à mainline, o ritmo de envio de
+patches diminui gradualmente. Linus lança novos kernels -rc aproximadamente uma
+vez por semana; uma série normal costuma chegar entre o -rc6 e o -rc9 antes que
+o kernel seja considerado suficientemente estável para o lançamento da versão
+final. Nesse ponto, todo o processo se reinicia.
+
+Como exemplo, veja como foi o ciclo de desenvolvimento da versão 5.4 (todas as
+datas em 2019):
+
+	==============  ===================================================
+	15 de setembro	Lançamento da versão estável 5.3
+	30 de setembro	5.4-rc1, janela de merge fechada
+	6 de outubro	5.4-rc2
+	13 de outubro	5.4-rc3
+	20 de outubro	5.4-rc4
+	27 de outubro	5.4-rc5
+	3 de novembro	5.4-rc6
+	10 de novembro	5.4-rc7
+	17 de novembro	5.4-rc8
+	24 de novembro	5.4 lançamento da versão estável ("stable release")
+	==============  ===================================================
+
+Como os desenvolvedores decidem quando encerrar o ciclo de desenvolvimento e
+criar a versão estável? A métrica mais importante utilizada é a lista de
+regressões em relação às versões anteriores. Nenhum bug é bem-vindo, mas
+aqueles que
+quebram sistemas que funcionavam no passado são considerados especialmente
+graves. Por esse motivo, patches que causam regressões são vistos com maus
+olhos e têm grande probabilidade de serem revertidas durante o período de
+estabilização.
+
+O objetivo dos desenvolvedores é corrigir todas as regressões conhecidas antes
+do lançamento da versão estável.  Na prática, esse nível de perfeição é difícil
+de alcançar; há muitas variáveis em um projeto desse porte.
+Chega um ponto em que adiar o lançamento final só piora o problema; a pilha de
+alterações aguardando a próxima janela de merge aumentará, criando ainda mais
+regressões na próxima vez. Portanto, a maioria dos kernels é lançada com algumas
+regressões conhecidas, embora, idealmente, nenhuma delas seja grave.
+
+Assim que uma versão estável é lançada, sua manutenção contínua é transferida
+para a equipe estável ("stable team"), atualmente composta por Greg
+Kroah-Hartman e Sasha Levin. A equipe estável lançará atualizações
+ocasionais para
+a versão estável usando o esquema de numeração 9.x.y.
+
+Para ser considerado para uma versão de atualização ("update release"), um
+patch deve (1) corrigir um bug significativo e (2) já ter sido incorporado
+à mainline do próximo kernel de desenvolvimento. Os kernels normalmente
+recebem atualizações estáveis por um pouco mais de um ciclo de desenvolvimento
+após o lançamento inicial. Assim, por exemplo, o histórico do kernel 5.2
+era o seguinte (todas as datas em 2019):
+
+	==============  ===============================
+	7 de julho		5.2 versão estável
+	14 de julho		5.2.1
+	21 de julho		5.2.2
+	26 de julho		5.2.3
+	28 de julho		5.2.4
+	31 de julho		5.2.5
+	...			...
+	11 de outubro	5.2.21
+	==============  ===============================
+
+A versão 5.2.21 foi a última atualização estável da série 5.2.
+
+Alguns kernels são designados como kernels de "longo prazo"; eles receberão
+suporte por um período mais longo. Consulte o seguinte link para obter a lista
+de versões de kernel de longo prazo ativas e seus respectivos mantenedores:
+
+	https://www.kernel.org/category/releases.html
+
+A seleção de um kernel para suporte a longo prazo ("long-term support") é
+puramente uma questão de um mantenedor ter a necessidade e o tempo para manter
+essa versão.  Não há planos conhecidos para suporte a longo prazo para qualquer
+versão futura específica.
+
+O ciclo de vida de um patch
+---------------------------
+
+Os patches não vão diretamente do teclado do desenvolvedor para o kernel
+principal ("mainline").  Em vez disso, existe um processo razoavelmente complexo
+(embora relativamente informal) projetado para garantir que cada patch seja
+revisado
+quanto à qualidade e que cada patch implemente uma alteração desejável no kernel
+mainline.
+
+Esse processo pode ser rápido para correções menores ou, no caso de mudanças
+grandes e controversas, levar anos. Grande parte da frustração dos
+desenvolvedores vem da falta de compreensão desse processo ou de tentativas de
+contorná-lo.
+
+Na esperança de reduzir essa frustração, este documento descreverá como um patch
+é inserido no kernel. O que se segue é uma introdução que descreve o
+processo de forma um tanto idealizada. Uma abordagem muito mais detalhada
+será apresentada em seções posteriores.
+
+As etapas pelas quais um patch passa são, geralmente:
+
+ - Projeto ("Design"). É aqui que os requisitos reais para o patch - e a
+   maneira como esses requisitos serão atendidos - são definidos. O trabalho
+   de projeto geralmente é feito sem envolver a comunidade, mas é melhor
+   fazer esse trabalho de forma aberta, se possível; isso pode economizar
+   muito tempo com reformulações posteriores.
+
+ - Revisão inicial ("Early review"). Os patches são enviados para a lista
+   de discussão relevante, e os desenvolvedores dessa lista respondem com
+   quaisquer comentários que possam ter. Esse processo deve revelar
+   quaisquer problemas importantes com um patch, se tudo correr bem.
+
+ - Revisão mais ampla ("Wider review"). Quando o patch estiver quase
+   pronto para inclusão na mainline, ele deve ser aceito por um mantenedor
+   de subsistema relevante - embora essa aceitação não seja uma garantia
+   de que o patch chegará à mainline. O patch aparecerá na árvore do
+   subsistema do mantenedor e nas árvores -next (descritas abaixo). Quando
+   o processo funciona, esta etapa leva a uma revisão mais extensa do
+   patch e à descoberta de quaisquer problemas resultantes da integração
+   deste patch com o trabalho que está sendo feito por outros.
+
+-  Observe que a maioria dos mantenedores também tem empregos regulares,
+   portanto, o merge do seu patch pode não ser a prioridade máxima deles.
+   Se o seu patch estiver recebendo feedback sobre mudanças necessárias,
+   você deve implementá-las ou justificar por que não devem ser feitas.
+   Se o seu patch não tiver reclamações de revisão, mas não estiver sendo
+   integrado pelo mantenedor do subsistema ou driver apropriado, você deve
+   persistir na atualização do patch para o kernel atual para que ele se
+   aplique corretamente e continuar enviando-o para revisão e merge.
+
+ - Integração na mainline. Por fim, um patch bem-sucedido será incorporado
+   ao repositório mainline gerenciado por Linus Torvalds. Novos comentários
+   ou problemas podem surgir nesta etapa; é fundamental que o desenvolvedor
+   responda prontamente a eles e solucione quaisquer falhas que surjam.
+
+ - Versão estável. A base de usuários afetada pelo patch agora é ampla;
+   consequentemente, novas falhas podem ser detectadas.
+
+ - Manutenção a longo prazo ("long-term maintenance"). Embora seja
+   plenamente possível que um desenvolvedor se esqueça de seu código após a
+   integração, tal comportamento tende a causar uma má impressão na
+   comunidade. A incorporação do código alivia parte do fardo da
+   manutenção, uma vez que outros desenvolvedores corrigirão possíveis
+   falhas decorrentes de mudanças na API. Contudo, o autor original deve
+   manter a responsabilidade sobre o código, caso deseje que ele
+   permaneça útil a longo prazo.
+
+Um dos maiores erros cometidos pelos desenvolvedores do kernel (ou seus
+empregadores) é tentar reduzir o processo a uma única etapa de "integração à
+mainline".  Essa abordagem invariavelmente leva à frustração de todos os
+envolvidos.
+
+Como os patches chegam ao Kernel
+--------------------------------
+
+Existe apenas uma pessoa que pode incorporar patches ao repositório mainline do
+kernel: Linus Torvalds. No entanto, dos mais de 9.500 patches integrados ao
+kernel 2.6.38, por exemplo, apenas 112 (cerca de 1,3%) foram selecionados
+diretamente por ele. O projeto do kernel há muito superou a escala em que um
+único desenvolvedor seria capaz de inspecionar e filtrar todas as contribuições
+sem auxílio. A solução adotada pela comunidade para gerenciar esse crescimento
+foi a implementação de uma hierarquia de mantenedores fundamentada em uma cadeia
+de confiança.
+
+A base de código do kernel é subdividida logicamente em subsistemas: rede,
+suporte a arquiteturas específicas, gerenciamento de memória, dispositivos de
+vídeo, entre outros. A maioria possui um mantenedor designado — um desenvolvedor
+com responsabilidade integral pelo código daquela área. Esses mantenedores
+atuam, em linhas gerais, como os guardiões de seus respectivos domínios, sendo
+os responsáveis por validar e aceitar patches para inclusão no kernel mainline.
+
+Cada mantenedor de subsistema gerencia sua própria versão da árvore de códigos
+do kernel, geralmente (mas nem sempre) utilizando a ferramenta de controle de
+versão git. Ferramentas como o git (e correlatas, como quilt ou mercurial)
+permitem que os mantenedores rastreiem uma lista de patches, incluindo
+informações de autoria e outros metadados. A qualquer momento, o mantenedor
+consegue identificar quais patches em seu repositório não constam na mainline.
+
+Quando a janela de merge é aberta, os mantenedores de alto nível solicitam que
+Linus realize o "pull" dos patches selecionados em seus respectivos repositórios
+para integração. Caso Linus concorde, o fluxo de patches sobe para o seu
+repositório, tornando-se parte do kernel mainline. O nível de atenção que Linus
+dedica a patches específicos recebidos em uma operação de pull varia; é evidente
+que, por vezes, ele os analisa minuciosamente. No entanto, como regra geral,
+Linus confia que os mantenedores de subsistemas não enviarão patches
+problemáticos para o topo da cadeia ("upstream").
+
+Os mantenedores de subsistemas, por sua vez, podem realizar o pull de patches de
+outros mantenedores. Por exemplo, a árvore de rede é construída a partir de
+patches que se acumularam primeiramente em árvores dedicadas a drivers de
+dispositivos de rede, redes sem fio, entre outras. Essa sequência de
+repositórios pode ser arbitrariamente longa, embora raramente exceda dois ou
+três elos. Cada mantenedor na cadeia confia naqueles que gerenciam as árvores de
+nível inferior; esse processo é conhecido como "cadeia de confiança".
+
+Claramente, em um sistema como este, a inclusão de patches no kernel depende de
+encontrar o mantenedor correto. Enviar patches diretamente para Linus não
+costuma ser o procedimento adequado.
+
+Árvores next ("Next trees")
+---------------------------
+
+A cadeia de árvores de subsistemas orienta o fluxo de patches para o kernel, mas
+também levanta uma questão interessante: e se alguém quiser analisar todos os
+patches que estão sendo preparados para a próxima janela de merge?
+Desenvolvedores estarão interessados em quais outras mudanças estão pendentes
+para verificar se há conflitos preocupantes; um patch que altere o protótipo de
+uma função essencial do kernel, por exemplo, entrará em conflito com quaisquer
+outros patches que utilizem a forma antiga dessa função. Revisores e testadores
+desejam acessar as mudanças em sua forma integrada antes que todas elas cheguem
+ao kernel mainline. Seria possível realizar o pull de alterações de todas as
+árvores de subsistemas relevantes, mas isso seria uma tarefa onerosa e propensa
+a erros.
+
+A resposta vem na forma das árvores -next, onde as árvores de subsistemas são
+reunidas para testes e revisão. A mais antiga dessas árvores, mantida por Andrew
+Morton, é chamada de "-mm" (sigla para "memory management", ou gerenciamento de
+memória, que deu origem ao nome). A árvore -mm integra patches de uma
+extensa lista de árvores de subsistemas e também contém alguns patches voltados
+para auxiliar na depuração ("debugging").
+
+Além disso, a -mm contém uma coleção significativa de patches selecionados
+diretamente por Andrew. Esses patches podem ter sido publicados em uma lista de
+discussão ("mailing list") ou podem se aplicar a uma parte do kernel para a qual
+não exista uma árvore de subsistema designada. Como resultado, a -mm opera como
+uma espécie de árvore de subsistema de última instância; se não houver outro
+caminho óbvio para um patch chegar à mainline, é provável que ele termine na
+-mm. Patches diversos que se acumulam na -mm serão, eventualmente, encaminhados
+para uma árvore de subsistema apropriada ou enviados diretamente para Linus. Em
+um ciclo de desenvolvimento típico, aproximadamente 5% a 10% dos patches que
+entram na mainline chegam lá via -mm.
+
+O patch -mm atual está disponível no diretório "mmotm" (-mm of the moment) em:
+
+	https://www.ozlabs.org/~akpm/mmotm/
+
+O uso da árvore MMOTM, entretanto, tende a ser uma experiência frustrante; há
+uma chance real de que o código sequer compile.
+
+A árvore principal para a integração de patches do próximo ciclo é a linux-next,
+mantida por Mark Brown. A linux-next é, por concepção, uma captura ("snapshot") do
+que se espera que a mainline venha a ser após o fechamento da próxima janela de
+merge. As árvores linux-next são anunciadas nas listas de discussão linux-kernel e
+linux-next assim que são consolidadas; elas podem ser baixadas em:
+
+	https://www.kernel.org/pub/linux/kernel/next/
+
+A linux-next tornou-se parte integrante do processo de desenvolvimento do
+kernel; idealmente, todos os patches incorporados durante uma determinada janela
+de merge devem ter sido integrados à linux-next algum tempo antes da abertura
+dessa janela.
+
+Árvores de Staging ("Staging trees")
+------------------------------------
+
+A árvore de código-fonte do kernel contém o diretório drivers/staging/, que
+abriga diversos subdiretórios de drivers ou sistemas de arquivos em processo
+de inclusão na árvore do kernel. Eles permanecem em drivers/staging/ enquanto
+demandam aprimoramentos; uma vez concluídos, podem ser movidos para o kernel
+propriamente dito. Esta é uma forma de rastrear drivers que ainda não
+atingiram os padrões de codificação ou qualidade do kernel Linux, mas que a
+comunidade pode desejar utilizar e acompanhar o desenvolvimento.
+
+Atualmente, Greg Kroah-Hartman mantém a árvore de staging. Drivers que ainda
+necessitam de ajustes são enviados a ele, cada um ocupando seu próprio
+subdiretório em drivers/staging/. Juntamente com os arquivos-fonte do driver,
+deve constar um arquivo TODO no diretório. O arquivo TODO lista as tarefas
+pendentes para a aceitação no kernel propriamente dito, além de uma lista de
+pessoas que devem ser copiadas ("Cc'd") em quaisquer patches relacionados ao
+driver. As regras atuais exigem que os drivers submetidos ao staging devam,
+no mínimo, compilar corretamente.
+
+O staging pode ser um caminho relativamente simples para inserir novos
+drivers na mainline onde, com sorte, atrairão a atenção de outros
+desenvolvedores e evoluirão rapidamente. Entretanto, a entrada no staging
+não encerra o processo; códigos que não apresentem progresso regular acabarão
+removidos. Além disso, os distribuidores tendem a ser relutantes em habilitar
+drivers de staging. Portanto, o staging é, na melhor das hipóteses, uma etapa
+temporária no percurso para se tornar um driver adequado para a mainline.
+
+Ferramentas
+-----------
+
+Conforme observado no texto anterior, o processo de desenvolvimento do
+kernel depende fortemente da capacidade de orquestrar coleções de patches em
+diversas direções. O sistema como um todo não funcionaria com a eficiência
+atual sem o auxílio de ferramentas adequadamente robustas. Tutoriais sobre o
+uso dessas ferramentas estão além do escopo deste documento, mas cabe aqui
+apresentar algumas orientações básicas.
+
+O sistema de gerenciamento de código-fonte predominante na comunidade do
+kernel é, de longe, o git. O git é um dos diversos sistemas de controle de
+versão distribuídos desenvolvidos pela comunidade de software livre. Ele é
+altamente otimizado para o desenvolvimento do kernel, apresentando excelente
+desempenho ao lidar com grandes repositórios e volumes massivos de patches.
+Também possui a reputação de ser complexo para aprender e operar, embora
+tenha evoluído significativamente com o tempo. Algum nível de domínio da
+ferramenta é praticamente um requisito para desenvolvedores de kernel; mesmo
+que não a utilizem em seu próprio fluxo de trabalho, precisarão do git para
+acompanhar as atividades de outros desenvolvedores (e da mainline).
+
+O git já está disponível nos repositórios de quase todas as distribuições
+Linux. A página oficial do projeto encontra-se em:
+
+	https://git-scm.com/
+
+Essa página contém links para documentações e tutoriais.
+
+Entre os desenvolvedores de kernel que não utilizam o git, a escolha mais
+popular é, quase certamente, o Mercurial:
+
+	https://www.selenic.com/mercurial/
+
+O Mercurial compartilha muitos recursos com o git, mas oferece uma interface
+que muitos consideram mais fácil de usar.
+
+A outra ferramenta que vale a pena conhecer é o Quilt:
+
+	https://savannah.nongnu.org/projects/quilt/
+
+O quilt é um sistema de gerenciamento de patches, em vez de um sistema de
+gerenciamento de código-fonte. Ele não rastreia o histórico ao longo do
+tempo; em vez disso, é orientado ao rastreamento de um conjunto específico de
+alterações em relação a uma base de código em evolução. Alguns mantenedores
+de subsistemas importantes usam o quilt para gerenciar patches destinados ao
+upstream. Para o gerenciamento de certos tipos de árvores (como a -mm, por
+exemplo), o quilt é a melhor ferramenta para o trabalho.
+
+Listas de discussão ("Mailing lists")
+-------------------------------------
+
+Grande parte do trabalho de desenvolvimento do kernel Linux é realizada por
+meio de listas de discussão ("mailing lists"). É difícil participar
+plenamente da comunidade sem ingressar em, pelo menos, uma lista em algum
+lugar. No entanto, as listas de discussão do Linux também representam um
+risco potencial para os desenvolvedores, que podem acabar soterrados por uma
+carga de mensagens eletrônicas, infringir as convenções utilizadas nas listas
+do Linux, ou ambos.
+
+A maioria das listas de discussão do kernel está hospedada em kernel.org; a
+lista principal pode ser encontrada em:
+
+	https://subspace.kernel.org
+
+Existem listas hospedadas em outros locais; por favor, verifique o arquivo
+MAINTAINERS para encontrar a lista relevante de qualquer subsistema
+específico.
+
+A principal lista de discussão para o desenvolvimento do kernel é,
+naturalmente, a linux-kernel. Esta lista é um lugar intimidador; o volume
+pode chegar a 500 mensagens por dia, o nível de ruído é alto, as conversas
+podem ser extremamente técnicas e os participantes nem sempre estão
+preocupados em demonstrar um alto grau de polidez. No entanto, não há outro
+lugar onde a comunidade de desenvolvimento do kernel se reúna como um todo;
+desenvolvedores que evitam esta lista perderão informações importantes.
+
+Existem algumas dicas que podem ajudar na sobrevivência à linux-kernel:
+
+ -  Direcione as mensagens da lista para uma pasta separada, em vez de
+    sua caixa de entrada principal. É preciso ser capaz de ignorar o fluxo
+    de mensagens por períodos prolongados.
+
+ - Não tente acompanhar todas as conversas — ninguém consegue. É importante
+   filtrar tanto pelo tópico de interesse (embora conversas longas possam se
+   desviar do assunto original sem alterar o campo de assunto do e-mail)
+   quanto pelas pessoas que estão participando.
+
+ - Não alimente os trolls. Se alguém estiver tentando provocar uma reação
+   irritada, ignore-o.
+
+ - Ao responder a um e-mail da linux-kernel (ou de outras listas), preserve
+   o cabeçalho Cc: para todos os envolvidos. Na ausência de um motivo forte
+   (como uma solicitação explícita), você nunca deve remover destinatários.
+   Certifique-se sempre de que a pessoa a quem você está respondendo esteja
+   na lista de Cc:. Essa convenção também torna desnecessário pedir
+   explicitamente para ser copiado nas respostas às suas postagens.
+
+ - Pesquise nos arquivos da lista (e na rede como um todo) antes de fazer
+   perguntas. Alguns desenvolvedores podem ficar impacientes com pessoas
+   que claramente não fizeram o "dever de casa".
+
+ - Use respostas intercaladas ("inline"), o que torna sua resposta mais
+   fácil de ler. (Ou seja, evite o "top-posting" — a prática de colocar
+   sua resposta acima do texto citado ao qual você está respondendo).
+   Para mais detalhes, veja:
+   :ref:`Documentation/process/submitting-patches.rst <interleaved_replies>`.
+
+ - Pergunte na lista de discussão correta. A linux-kernel pode ser o
+   ponto de encontro geral, mas não é o melhor lugar para encontrar
+   desenvolvedores de todos os subsistemas.
+
+O último ponto — encontrar a lista de discussão correta — é onde
+desenvolvedores iniciantes
+costumam errar. Alguém que faça uma pergunta relacionada a
+redes na linux-kernel quase certamente receberá uma sugestão educada para
+perguntar na lista netdev, pois essa é a lista frequentada pela maioria
+dos desenvolvedores de rede. Existem outras listas para os subsistemas
+SCSI, video4linux, IDE, sistemas de arquivos ("filesystems"), etc. O
+melhor lugar para procurar por listas de discussão é no arquivo MAINTAINERS que
+acompanha o código-fonte do kernel.
+
+Iniciando no desenvolvimento do Kernel
+--------------------------------------
+
+Dúvidas sobre como iniciar no processo de desenvolvimento do kernel são
+comuns — tanto por parte de indivíduos quanto de empresas. Igualmente
+comuns são os tropeços que tornam o início desse relacionamento mais difícil
+do que precisa ser.
+
+As empresas costumam buscar a contratação de desenvolvedores conhecidos
+para dar o pontapé inicial em um grupo de desenvolvimento. Esta pode ser,
+de fato, uma técnica eficaz. No entanto, ela também tende a ser cara e não
+contribui muito para expandir o grupo de desenvolvedores experientes de
+kernel. É possível capacitar desenvolvedores internos no desenvolvimento do
+kernel Linux, desde que se invista um pouco de tempo. Dedicar esse tempo
+pode dotar um empregador de um grupo de desenvolvedores que compreendem
+tanto o kernel quanto a empresa, e que também podem ajudar a treinar
+outros. A médio prazo, esta é frequentemente a abordagem mais proveitosa.
+
+Desenvolvedores individuais muitas vezes sentem-se, compreensivelmente,
+perdidos sobre por onde começar. Iniciar com um projeto grande pode ser
+intimidador; geralmente deseja-se "testar o terreno" com algo menor
+primeiro. Este é o ponto onde alguns desenvolvedores se lançam na criação
+de patches que corrigem erros ortográficos ou problemas menores de estilo
+de codificação (coding style). Infelizmente, tais patches criam um nível
+de ruído que distrai a comunidade de desenvolvimento como um todo; por
+isso, cada vez mais, eles são vistos com desdém. Novos desenvolvedores que
+desejam se apresentar à comunidade não receberão o tipo de recepção que
+esperam por meio desses métodos.
+
+Andrew Morton oferece este conselho para aspirantes a desenvolvedores de
+kernel
+
+::
+
+	O projeto nº 1 para todos os iniciantes no kernel certamente deve
+	ser "certificar-se de que o kernel funcione perfeitamente o tempo
+	todo em todas as máquinas em que você puder colocar as mãos".
+	Geralmente, a maneira de fazer isso é trabalhar com outros para
+	que as coisas sejam corrigidas (isso pode exigir persistência!),
+	mas tudo bem — isso faz parte do desenvolvimento do kernel.
+
+(https://lwn.net/Articles/283982/).
+
+Na ausência de problemas óbvios para corrigir, os desenvolvedores são
+aconselhados a olhar para as listas atuais de regressões e bugs abertos em
+geral. Nunca há escassez de problemas que precisem de correção; ao abordar
+essas questões, os desenvolvedores ganharão experiência com o processo
+enquanto, ao mesmo tempo, constroem respeito junto ao restante da
+comunidade de desenvolvimento.
-- 
2.53.0