[PATCH v2] docs: pt_BR: process: Translate stable kernel rules guide

[PATCH v2] docs: pt_BR: process: Translate stable kernel rules guide

[Matheus Patriota]

Translates the documentation regarding stable kernel rules into
Brazilian Portuguese, maintaining consistency with original
formatting rules.

Changes in v2::

I changed the patch name to avoid conflicts with the original patch.
I adjusted the dashes by replacing them with commas.
Regarding the typo, I corrected "concluidasamp" to "concluídas".

Signed-off-by: Matheus Patriota <matheuslinuxdeb@gmail.com>
---
 Documentation/translations/pt_BR/index.rst    |   1 +
 .../pt_BR/process/stable-kernel-rules.rst     | 232 ++++++++++++++++++
 2 files changed, 233 insertions(+)
 create mode 100644 Documentation/translations/pt_BR/process/stable-kernel-rules.rst

diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
index 7a488f662..e761ee0eb 100644
--- a/Documentation/translations/pt_BR/index.rst
+++ b/Documentation/translations/pt_BR/index.rst
@@ -78,3 +78,4 @@ kernel e sobre como ver seu trabalho integrado.
    Processo do subsistema SoC <process/maintainer-soc>
    Conformidade de DTS para SoC <process/maintainer-soc-clean-dts>
    Processo do subsistema KVM x86 <process/maintainer-kvm-x86>
+   Regras para kernels estáveis <process/stable-kernel-rules>
diff --git a/Documentation/translations/pt_BR/process/stable-kernel-rules.rst b/Documentation/translations/pt_BR/process/stable-kernel-rules.rst
new file mode 100644
index 000000000..e0b0ff3ed
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/stable-kernel-rules.rst
@@ -0,0 +1,232 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. _stable_kernel_rules:
+
+Tudo o que você sempre quis saber sobre as versões -stable do Linux
+===================================================================
+
+Regras sobre que tipos de patches são aceitos — e quais não são — na árvore
+"-stable":
+
+- Ele, ou uma correção equivalente, já deve existir na linha principal (upstream) do Linux.
+- Deve ser obviamente correto e testado.
+- Não deve conter mais de 100 linhas, incluindo o contexto.
+- Deve seguir as
+  :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+  regras.
+- Deve corrigir um bug real que incomoda as pessoas ou simplesmente adicionar um ID de dispositivo.
+
+Para detalhar o primeiro ponto:
+
+  - Ele corrige um problema como um "oops", um travamento, corrupção de dados, uma falha de segurança
+    real, uma peculiaridade de hardware, um erro de compilação (mas não para itens marcados
+    como CONFIG_BROKEN) ou algum problema do tipo "oh, isso não é bom".
+  - Problemas graves relatados por um usuário de um kernel de distribuição também
+    podem ser considerados se corrigirem um problema notável de desempenho ou interatividade.
+    Como essas correções não são tão óbvias e apresentam um risco maior de uma sutil
+    regressão, elas só devem ser enviadas por um mantenedor de kernel de distribuição
+    e incluir um adendo com link para um registro no Bugzilla (caso exista) e
+    informações adicionais sobre o impacto visível para o usuário.
+  - Nada do tipo "isso poderia ser um problema...", como uma "condição de corrida
+    teórica", a menos que também seja fornecida uma explicação de como o bug pode ser explorado.
+  - Nada de correções "triviais" que não tragam benefícios aos usuários (alterações de ortografia, limpeza
+    de espaços em branco, etc.).
+
+Procedimento para enviar patches para a árvore -stable
+------------------------------------------------------
+
+.. note::
+
+   Correções de segurança não devem ser tratadas (exclusivamente) pelo processo de revisão da
+   série estável, mas devem seguir os procedimentos descritos em
+   :ref:`Documentation/process/security-bugs.rst <securitybugs>`.
+
+Existem três opções para enviar mudanças para as árvores -stable:
+
+1. Adicionar uma 'tag stable' na descrição de um patch que você envia para
+   inclusão na linha principal.
+2. Pedir à equipe do stable para incluir um patch que já tenha sido integrado à linha principal.
+3. Enviar um patch para a equipe do stable que seja equivalente a uma alteração já
+   integrada à linha principal.
+
+As seções abaixo descrevem cada uma das opções com mais detalhes.
+
+A :ref:`option_1` é **fortemente** preferida, sendo a mais fácil e comum.
+A :ref:`option_2` destina-se principalmente a alterações para as quais o backporting não foi considerado
+no momento da submissão. A :ref:`option_3` é uma alternativa às duas opções anteriores
+para casos em que um patch integrado à linha principal precisa de ajustes para ser aplicado em séries
+mais antigas (por exemplo, devido a alterações na API).
+
+Ao utilizar as opções 2 ou 3, você pode solicitar que sua alteração seja incluída em séries
+estáveis específicas. Ao fazer isso, certifique-se de que a correção ou uma equivalente seja aplicável,
+submetida ou já esteja presente em todas as árvores estáveis mais recentes que ainda recebem suporte. Isso é
+feito para evitar regressões que os usuários poderiam encontrar posteriormente ao atualizar se,
+e.g. uma correção integrada ao 5.19-rc1 fosse retroportada para o 5.10.y, mas não para o 5.15.y.
+
+.. _option_1:
+
+Opção 1
+*******
+
+Para que um patch que você envia para inclusão na linha principal seja automaticamente coletado mais tarde
+para as árvores estáveis, adicione esta tag na área de sign-off::
+
+  Cc: stable@vger.kernel.org
+
+Use ``Cc: stable@kernel.org`` em vez disso ao corrigir vulnerabilidades não divulgadas:
+reduz a chance de expor acidentalmente a correção ao público por meio do
+'git send-email', já que e-mails enviados para esse endereço não são entregues em lugar nenhum.
+
+Assim que o patch estiver na linha principal, ele será aplicado à árvore estável sem
+que nada mais precise ser feito pelo autor ou mantenedor do subsistema.
+
+Para enviar instruções adicionais à equipe do stable, use um comentário inline no estilo shell
+para passar notas arbitrárias ou predefinidas:
+
+* Especifique quaisquer pré-requisitos adicionais de patch para o cherry picking::
+
+    Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
+    Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
+    Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
+    Cc: <stable@vger.kernel.org> # 3.3.x
+    Signed-off-by: Ingo Molnar <mingo@elte.hu>
+
+A sequência de tags tem o significado de::
+
+    git cherry-pick a1f84a3
+    git cherry-pick 1b9508f
+    git cherry-pick fd21073
+    git cherry-pick <este commit>
+
+Observe que, para uma série de patches, você não precisa listar como pré-requisitos os
+patches presentes na própria série. Por exemplo, se você tiver a seguinte
+série de patches::
+
+    patch1
+    patch2
+
+onde o patch2 depende do patch1, você não precisa listar o patch1 como
+pré-requisito do patch2 se você já tiver marcado o patch1 para inclusão no
+stable.
+
+* Indique os pré-requisitos de versão do kernel::
+
+    Cc: <stable@vger.kernel.org> # 3.3.x
+
+A tag tem o significado de::
+
+    git cherry-pick <este commit>
+
+Para cada árvore "-stable" começando com a versão especificada.
+
+  Nota, essa marcação é desnecessária se a equipe do stable puder derivar as
+  versões apropriadas a partir das tags Fixes:.
+
+* Adiar a coleta de patches::
+
+    Cc: <stable@vger.kernel.org> # after -rc3
+
+* Apontar problemas conhecidos::
+
+    Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
+
+Além disso, existe uma variante da tag stable que você pode usar para fazer com que as ferramentas de
+backporting da equipe do stable (por exemplo, AUTOSEL ou scripts que buscam commits
+contendo uma tag 'Fixes:') ignorem uma alteração::
+
+    Cc: <stable+noautosel@kernel.org> # o motivo vai aqui, e deve estar presente
+
+.. _option_2:
+
+Opção 2
+*******
+
+Se o patch já tiver sido mesclado à linha principal, envie um e-mail para
+stable@vger.kernel.org contendo o assunto do patch, o ID do commit,
+por que
+você acha que ele deve ser aplicado e para quais versões do kernel você deseja que ele
+seja aplicado.
+
+.. _option_3:
+
+Opção 3
+*******
+
+Envie o patch, após verificar se ele segue as regras acima, para
+stable@vger.kernel.org e mencione as versões do kernel às quais você deseja que ele seja aplicado.
+Ao fazer isso, você deve anotar o ID do commit upstream no changelog da sua
+submissão com uma linha separada acima do texto do commit, desta forma::
+
+    commit <sha1> upstream.
+
+Ou, alternativamente::
+
+   [ Upstream commit <sha1> ]
+
+Se o patch enviado divergir do patch upstream original (por exemplo
+porque teve que ser ajustado para a API mais antiga), isso deve ser muito claramente
+documentado e justificado na descrição do patch.
+
+Após a submissão
+----------------
+
+O remetente receberá um ACK quando o patch tiver sido aceito na
+fila, ou um NAK se o patch for rejeitado. Esta resposta pode levar alguns
+dias, de acordo com as agendas dos membros da equipe do stable.
+
+Se aceito, o patch será adicionado à fila -stable, para revisão por outros
+desenvolvedores e pelo mantenedor do subsistema relevante.
+
+Ciclo de revisão
+----------------
+
+- Quando os mantenedores do -stable decidirem por um ciclo de revisão, os patches serão
+  enviados para o comitê de revisão, e para o mantenedor da área afetada do
+  patch (a menos que o remetente seja o mantenedor da área) e CC: para
+  a lista de discussão linux-kernel.
+- O comitê de revisão tem 48 horas para dar ACK ou NAK no patch.
+- Se o patch for rejeitado por um membro do comitê, ou membros da lista linux-kernel
+  reclamarem do patch, trazendo problemas que os mantenedores e
+  membros não perceberam, o patch será descartado da fila.
+- Os patches que receberam ACK serão postados novamente como parte de uma versão candidata (-rc)
+  para serem testados por desenvolvedores e testadores.
+- Normalmente apenas um lançamento -rc é feito, no entanto, se houver quaisquer problemas
+  pendentes, alguns patches podem ser modificados ou descartados ou patches adicionais podem
+  ser enfileirados. Lançamentos -rc adicionais são então lançados e testados até que nenhum
+  problema seja encontrado.
+- Responder aos lançamentos -rc pode ser feito na lista de discussão enviando
+  um e-mail "Tested-by:" com qualquer informação de teste desejada. As tags "Tested-by:"
+  serão coletadas e adicionadas ao commit de lançamento.
+- Ao final do ciclo de revisão, o novo lançamento -stable será lançado
+  contendo todos os patches enfileirados e testados.
+- Patches de segurança serão aceitos na árvore -stable diretamente da
+  equipe de segurança do kernel, e não passarão pelo ciclo normal de revisão.
+  Entre em contato com a equipe de segurança do kernel para mais detalhes sobre este procedimento.
+
+Árvores
+-------
+
+- As filas de patches, tanto para versões concluídasamp; quanto para versões em
+  andamento podem ser encontradas em:
+
+    https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
+
+- Os lançamentos finalizados e marcados (tagged) de todos os kernels estáveis podem ser encontrados
+  em branches separados por versão em:
+
+    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
+
+- A versão candidata de todas as versões estáveis do kernel pode ser encontrada em:
+
+    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
+
+  .. warning::
+     A árvore -stable-rc é um instantâneo no tempo da árvore stable-queue e
+     mudará frequentemente, portanto, passará por rebase com frequência.
+     Ela deve ser utilizada apenas para
+     fins de teste (por exemplo, para ser consumida por sistemas de CI).
+
+Comitê de revisão
+-----------------
+
+- Este é composto por um número de desenvolvedores de kernel que se voluntariaram para
+  esta tarefa, e alguns que não o fizeram.
-- 
2.53.0