Re: [PATCH v2 3/3] docs: translations: pt_BR: Translate stable-kernel-rules.rst

[Daniel Pereira]

On Tue, Oct 20, 2026 at 1:13 AM Lucas Adryell Ramalho
<lucasadramalho@xxxxxxxxx> wrote:

Hi Lucas,

Thanks for switching to the pt_BR_submittingpatches and
pt_BR_securitybugs labels, both resolve correctly now. I found one
sentence where the meaning got inverted:

> +uma equivalente seja aplicável, tenha sido enviada ou já esteja presente em
> +todas as árvores stable mais novas que ainda recebem suporte. Isso evita
> +regressões que os usuários poderiam encontrar ao atualizar. Por exemplo,
> +uma correção integrada para 5.19-rc1 poderia ser portada para
> +5.10.y, mas não para 5.15.y.

The original says:

This is meant to prevent regressions that users might later
encounter on updating, if e.g. a fix merged for 5.19-rc1 would be
backported to 5.10.y, but not to 5.15.y.

In the English text the example describes the situation that causes
the regression (a fix backported to an older tree but missing from a
newer one). As translated, it reads as if this were allowed. Something
like this keeps the original meaning:

Isso evita regressões que os usuários poderiam encontrar ao
atualizar caso, por exemplo, uma correção integrada no 5.19-rc1
fosse portada para o 5.10.y, mas não para o 5.15.y.

Thanks,
Daniel


Em ter., 20 de out. de 2026 às 01:14, Lucas Adryell Ramalho
<lucasadramalho@xxxxxxxxx> escreveu:
>
> Translate the stable kernel rules documentation into Brazilian Portuguese.
>
> Signed-off-by: Lucas Adryell Ramalho <lucasadramalho@xxxxxxxxx>
> ---
>  .../translations/pt_BR/process/index.rst      |   1 +
>  .../pt_BR/process/stable-kernel-rules.rst     | 258 ++++++++++++++++++
>  2 files changed, 259 insertions(+)
>  create mode 100644 Documentation/translations/pt_BR/process/stable-kernel-rules.rst
>
> diff --git a/Documentation/translations/pt_BR/process/index.rst b/Documentation/translations/pt_BR/process/index.rst
> index 31704e28d..29f6c7735 100644
> --- a/Documentation/translations/pt_BR/process/index.rst
> +++ b/Documentation/translations/pt_BR/process/index.rst
> @@ -63,6 +63,7 @@ Estas são as regras pelas quais tentamos viver na comunidade do kernel
>     Declaração de Aplicação do Kernel Linux <kernel-enforcement-statement>
>     Declaração sobre Drivers do Kernel <kernel-driver-statement>
>     A interface de drivers do kernel Linux <stable-api-nonsense>
> +   Tudo o que você sempre quis saber sobre as versões estáveis do Linux <stable-kernel-rules>
>     Estilo de gerenciamento do kernel Linux <management-style>
>     Diretrizes para pesquisadores <researcher-guidelines>
>     Assistentes de código <coding-assistants>
> 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..201c87150
> --- /dev/null
> +++ b/Documentation/translations/pt_BR/process/stable-kernel-rules.rst
> @@ -0,0 +1,258 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +.. _pt_BR_stable_kernel_rules:
> +
> +Tudo o que você sempre quis saber sobre as versões estáveis do Linux
> +====================================================================
> +
> +Regras sobre quais tipos de correções são aceitos na árvore "-stable" e
> +quais não são:
> +
> +- A correção, ou uma equivalente, já deve existir na linha principal do
> +  Linux (upstream).
> +- Deve estar obviamente correta e ter sido testada.
> +- Não pode ter mais de 100 linhas, incluindo o contexto.
> +- Deve seguir as regras de
> +  :ref:`Documentation/translations/pt_BR/process/submitting-patches.rst
> +  <pt_BR_submittingpatches>`.
> +- Deve corrigir um erro real que afete as pessoas ou apenas adicionar um ID
> +  de dispositivo. Em mais detalhes, o primeiro caso inclui:
> +
> +  - Corrigir um problema como um oops, travamento, corrupção de dados,
> +    problema real de segurança, peculiaridade de hardware, erro de
> +    compilação (exceto itens CONFIG_BROKEN) ou algum problema do tipo "isso
> +    não é nada bom".
> +  - Problemas graves relatados por usuários de um kernel de distribuição
> +    também podem ser considerados se as correções resolverem um problema
> +    notável de desempenho ou interatividade. Como essas correções não são
> +    tão óbvias e apresentam maior risco de causar uma regressão sutil, elas
> +    só devem ser enviadas pelo mantenedor do kernel da distribuição e
> +    devem incluir um complemento com um link para uma entrada no Bugzilla,
> +    se houver, e informações adicionais sobre o impacto percebido pelo
> +    usuário.
> +  - Não são aceitos problemas do tipo "isto pode ser um problema...", como
> +    uma "condição de corrida teórica", a menos que também seja fornecida
> +    uma explicação de como o erro pode ser explorado.
> +  - Não são aceitas correções "triviais" sem benefício para os usuários
> +    (alterações ortográficas, limpeza de espaços em branco etc.).
> +
> +
> +Procedimento para enviar correções à árvore -stable
> +----------------------------------------------------
> +
> +.. note::
> +
> +   Correções de segurança não devem ser tratadas exclusivamente pelo
> +   processo de revisão -stable; devem seguir os procedimentos em
> +   :ref:`Documentation/translations/pt_BR/process/security-bugs.rst
> +   <pt_BR_securitybugs>`.
> +
> +Há três opções para enviar uma alteração às árvores -stable:
> +
> +1. Adicionar uma "stable tag" à descrição de uma correção que será enviada
> +   para inclusão na linha principal.
> +2. Pedir à equipe stable que inclua uma correção já integrada à linha
> +   principal.
> +3. Enviar à equipe stable uma correção equivalente a uma alteração já
> +   integrada à linha principal.
> +
> +As seções abaixo descrevem cada opção em mais detalhes.
> +
> +A :ref:`pt_BR_option_1` é **fortemente** preferida; é a opção mais fácil e
> +mais comum.
> +A :ref:`pt_BR_option_2` destina-se principalmente a alterações para as
> +quais o backport não foi considerado no momento do envio.
> +A :ref:`pt_BR_option_3` é uma alternativa às opções anteriores quando uma
> +correção integrada à linha principal precisa de ajustes para ser aplicada
> +a séries mais antigas (por exemplo, devido a alterações na API).
> +
> +Ao usar a opção 2 ou 3, você pode pedir que sua alteração seja incluída em
> +séries stable específicas. Nesse caso, certifique-se de que a correção ou
> +uma equivalente seja aplicável, tenha sido enviada ou já esteja presente em
> +todas as árvores stable mais novas que ainda recebem suporte. Isso evita
> +regressões que os usuários poderiam encontrar ao atualizar. Por exemplo,
> +uma correção integrada para 5.19-rc1 poderia ser portada para
> +5.10.y, mas não para 5.15.y.
> +
> +.. _pt_BR_option_1:
> +
> +Opção 1
> +*******
> +
> +Para que uma correção enviada para inclusão na linha principal seja
> +selecionada automaticamente depois pelas árvores stable, adicione esta
> +etiqueta à seção de assinaturas (sign-off)::
> +
> +  Cc: stable@xxxxxxxxxxxxxxx
> +
> +Use ``Cc: stable@xxxxxxxxxx`` em vez disso ao corrigir vulnerabilidades
> +ainda não divulgadas: isso reduz a chance de expor acidentalmente a
> +correção ao público por meio do 'git send-email', pois as mensagens
> +enviadas a esse endereço não são entregues.
> +
> +Depois que a correção for integrada à linha principal, ela será aplicada à
> +árvore stable sem que o autor ou o mantenedor do subsistema precise fazer
> +mais nada.
> +
> +Para enviar instruções adicionais à equipe stable, use um comentário em
> +linha no estilo do shell para passar observações arbitrárias ou
> +predefinidas:
> +
> +* Especifique pré-requisitos adicionais para a seleção por cherry-pick::
> +
> +    Cc: <stable@xxxxxxxxxxxxxxx> # 3.3.x: a1f84a3: sched: Check for idle
> +    Cc: <stable@xxxxxxxxxxxxxxx> # 3.3.x: 1b9508f: sched: Rate-limit newidle
> +    Cc: <stable@xxxxxxxxxxxxxxx> # 3.3.x: fd21073: sched: Fix affinity logic
> +    Cc: <stable@xxxxxxxxxxxxxxx> # 3.3.x
> +    Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
> +
> +  A sequência de etiquetas indica que se deve executar::
> +
> +    git cherry-pick a1f84a3
> +    git cherry-pick 1b9508f
> +    git cherry-pick fd21073
> +    git cherry-pick <this commit>
> +
> +  Observe que, em uma série de correções, não é necessário listar como
> +  pré-requisitos as correções que fazem parte da própria série. Por
> +  exemplo, nesta série::
> +
> +    patch1
> +    patch2
> +
> +  patch2 depende de patch1, mas não é necessário listar patch1 como
> +  pré-requisito de patch2 se você já tiver marcado patch1 para inclusão no
> +  stable.
> +
> +* Indique os pré-requisitos de versão do kernel::
> +
> +    Cc: <stable@xxxxxxxxxxxxxxx> # 3.3.x
> +
> +  A etiqueta indica que se deve executar::
> +
> +    git cherry-pick <this commit>
> +
> +  em cada árvore -stable a partir da versão especificada.
> +
> +  Observe que essa etiqueta é desnecessária se a equipe stable puder
> +  deduzir as versões apropriadas a partir das etiquetas Fixes:.
> +
> +* Adiar a inclusão de correções::
> +
> +    Cc: <stable@xxxxxxxxxxxxxxx> # after -rc3
> +
> +* Aponte problemas conhecidos::
> +
> +    Cc: <stable@xxxxxxxxxxxxxxx> # see patch description, needs adjustments for <= 6.3
> +
> +Também há uma variante da etiqueta stable que pode ser usada para fazer com
> +que as ferramentas de backport da equipe stable (por exemplo, AUTOSEL ou
> +scripts que procuram commits com uma etiqueta 'Fixes:') ignorem uma
> +alteração::
> +
> +     Cc: <stable+noautosel@xxxxxxxxxx> # reason goes here, and must be present
> +
> +.. _pt_BR_option_2:
> +
> +Opção 2
> +*******
> +
> +Se a correção já tiver sido integrada à linha principal, envie um e-mail
> +para stable@xxxxxxxxxxxxxxx com o assunto da correção, o ID do commit, o
> +motivo pelo qual você acredita que ela deve ser aplicada e as versões do
> +kernel às quais deve ser aplicada.
> +
> +.. _pt_BR_option_3:
> +
> +Opção 3
> +*******
> +
> +Depois de verificar que a correção segue as regras acima, envie-a para
> +stable@xxxxxxxxxxxxxxx e indique as versões do kernel às quais deseja que
> +ela seja aplicada. Nesse caso, você deve indicar o ID do commit upstream no
> +registro de alterações do envio, em uma linha separada acima do texto do
> +commit, assim::
> +
> +  commit <sha1> upstream.
> +
> +Ou, alternativamente::
> +
> +  [ Upstream commit <sha1> ]
> +
> +Se a correção enviada diferir da correção upstream original (por exemplo,
> +porque precisou ser adaptada à API mais antiga), isso deve ser documentado
> +e justificado com muita clareza na descrição da correção.
> +
> +
> +Acompanhamento do envio
> +-----------------------
> +
> +O remetente receberá um ACK quando a correção for aceita na fila, ou um NAK
> +se for rejeitada. Essa resposta pode levar alguns dias, dependendo da
> +disponibilidade dos membros da equipe stable.
> +
> +Se for aceita, a correção será adicionada à fila -stable para revisão por
> +outros desenvolvedores e pelo mantenedor do subsistema relevante.
> +
> +
> +Ciclo de revisão
> +----------------
> +
> +- Quando os mantenedores -stable decidirem iniciar um ciclo de revisão, as
> +  correções serão enviadas ao comitê de revisão, ao mantenedor da área
> +  afetada pela correção (a menos que o remetente seja o mantenedor dessa
> +  área) e em cópia (CC:) para a lista de discussão linux-kernel.
> +- O comitê de revisão tem 48 horas para aprovar (ACK) ou rejeitar (NAK) a
> +  correção.
> +- Se um membro do comitê rejeitar a correção ou membros da lista
> +  linux-kernel apresentarem objeções levantando problemas que os
> +  mantenedores e os membros não perceberam, a correção será removida da
> +  fila.
> +- As correções aprovadas serão publicadas novamente como parte de uma
> +  versão candidata (-rc), para serem testadas por desenvolvedores e
> +  testadores.
> +- Geralmente é publicada apenas uma versão -rc. No entanto, se houver
> +  problemas pendentes, algumas correções poderão ser modificadas ou
> +  removidas, ou outras poderão ser adicionadas à fila. Nesse caso, versões
> +  -rc adicionais serão publicadas e testadas até que nenhum problema seja
> +  encontrado.
> +- É possível responder às versões -rc na lista de discussão enviando um
> +  e-mail "Tested-by:" com as informações de teste desejadas. As etiquetas
> +  "Tested-by:" serão reunidas e adicionadas ao commit de lançamento.
> +- Ao final do ciclo de revisão, a nova versão -stable será lançada com
> +  todas as correções enfileiradas e testadas.
> +- Correções de segurança serão aceitas diretamente na árvore -stable pela
> +  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 saber
> +  mais sobre esse procedimento.
> +
> +
> +Árvores
> +-------
> +
> +- As filas de correções, tanto das versões concluídas quanto das versões em
> +  andamento, podem ser encontradas em:
> +
> +    https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
> +
> +- As versões finalizadas e identificadas por tags de todos os kernels
> +  estáveis podem ser encontradas em ramificações separadas por versão em:
> +
> +    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
> +
> +- As versões candidatas de todas as versões do kernel stable podem ser
> +  encontradas em:
> +
> +    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
> +
> +  .. warning::
> +     A árvore -stable-rc é um instantâneo da árvore stable-queue e muda com
> +     frequência; por isso, é rebaseada frequentemente. Ela deve ser usada
> +     apenas para testes (por exemplo, por sistemas de integração contínua).
> +
> +
> +Comitê de revisão
> +-----------------
> +
> +- É formado por vários desenvolvedores do kernel que se voluntariaram para
> +  essa tarefa e por alguns que não se voluntariaram.
> --
> 2.55.0
>