docs: pt_BR: process: Translate the patch followthrough guide

Translates the section 6.followthrough.rst to Brazilian Portuguese
for the process directory.

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

Documentation/translations/pt_BR/process/6.Followthrough.rst

@@ -0,0 +1,220 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Acompanhamento
+==============
+
+Neste ponto, você seguiu as diretrizes apresentadas até aqui e, com a
+adição de suas próprias habilidades de engenharia, enviou uma série perfeita
+de patches. Um dos maiores erros que até mesmo desenvolvedores experientes
+do kernel podem cometer é concluir que o seu trabalho agora está concluído.
+Na verdade, o envio de patches indica uma transição para a próxima etapa
+do processo, possivelmente com uma quantidade considerável de trabalho
+ainda por fazer.
+
+É raro um patch ser tão bom em seu primeiro envio que não haja margem para
+melhorias. O processo de desenvolvimento do kernel reconhece esse fato e,
+como resultado, é fortemente orientado para o aprimoramento do código
+enviado. Espera-se que você, como autor desse código, trabalhe junto à
+comunidade do kernel para garantir que seu código esteja de acordo com os
+padrões de qualidade do kernel. A falha em participar desse processo muito
+provavelmente impedirá a inclusão de seus patches na árvore principal
+(*mainline*).
+
+
+Trabalhando com revisores
+-------------------------
+
+Um patch de qualquer relevância resultará em uma série de comentários de outros
+desenvolvedores à medida que eles revisam o código. Trabalhar com revisores
+pode ser, para muitos desenvolvedores, a parte mais intimidadora do processo
+de desenvolvimento do kernel. No entanto, a vida pode se tornar muito mais
+fácil se você mantiver algumas coisas em mente:
+
+* Se você explicou bem o seu patch, os revisores entenderão o seu valor
+  e o porquê de você ter tido o trabalho de escrevê-lo. Contudo, esse valor
+  não os impedirá de fazer uma pergunta fundamental: como será manter um
+  kernel com este código inserido nele daqui a cinco ou dez anos? Muitas das
+  mudanças que podem lhe pedir para fazer — desde ajustes de estilo de código
+  até reescritas substanciais — vêm do entendimento de que o Linux ainda estará
+  por aqui e sob desenvolvimento daqui a uma década.
+
+* A revisão de código é um trabalho árduo e uma ocupação relativamente
+  ingrata; as pessoas lembram quem escreveu o código do kernel, mas há pouca
+  fama duradoura para aqueles que o revisaram. Portanto, os revisores podem
+  ficar ranzinzas, especialmente quando veem os mesmos erros sendo cometidos
+  repetidamente. Se você receber uma revisão que pareça irritada, insultuosa
+  ou abertamente ofensiva, resista ao impulso de responder à altura. A revisão
+  de código diz respeito ao código, não às pessoas, e os revisores de código
+  não estão atacando você pessoalmente.
+
+* Da mesma forma, os revisores de código não estão tentando promover os
+  interesses de seus empregadores em detrimento dos seus. Os desenvolvedores
+  do kernel geralmente esperam continuar trabalhando no kernel daqui a muitos
+  anos, mas entendem que seu empregador pode mudar. Quase sem exceção, eles
+  estão verdadeiramente trabalhando em prol da criação do melhor kernel possível;
+  eles não estão tentando causar desconforto aos concorrentes de seus empregadores.
+
+* Esteja preparado para solicitações aparentemente tolas de mudanças no estilo
+  de codificação e pedidos para refatorar parte do seu código em seções
+  compartilhadas do kernel. Uma das funções dos mantenedores é manter as coisas
+  com a mesma aparência. Às vezes, isso significa que aquele truque inteligente
+  (*clever hack*) em seu driver para contornar um problema
+
+Note que você não precisa concordar com todas as mudanças sugeridas pelos
+revisores. Se você acredita que o revisor entendeu mal o seu código, explique
+o que realmente está acontecendo. Se tiver uma objeção técnica a uma mudança
+sugerida, descreva-a e justifique a sua solução para o problema. Se as suas
+explicações fizerem sentido, o revisor as aceitará. Contudo, caso a sua
+explicação não seja persuasiva — especialmente se outros começarem a concordar
+com o revisor —, reserve um tempo para repensar as coisas. Pode ser fácil ficar
+ceguificado por sua própria solução para um problema, a ponto de não perceber
+que algo está fundamentalmente errado ou que, talvez, você não esteja sequer
+resolvendo o problema certo.
+
+Andrew Morton sugeriu que todo comentário de revisão que não resulte em uma
+alteração de código deveria, em vez disso, resultar em um comentário adicional
+no próprio código; isso pode ajudar os futuros revisores a evitar as dúvidas
+que surgiram da primeira vez.
+
+Um erro fatal é ignorar os comentários de revisão na esperança de que eles
+desapareçam. Eles não vão desaparecer. Se você reenviar o código sem ter
+respondido aos comentários que recebeu da vez anterior, é provável que descubra
+que os seus patches não vão a lugar nenhum.
+
+Por falar em reenviar código: tenha em mente que os revisores não vão se
+lembrar de todos os detalhes do código que você enviou da última vez. Portanto,
+é sempre uma boa ideia lembrar os revisores dos problemas levantados
+anteriormente e de como você lidou com eles; o registro de alterações
+(*changelog*) do patch é um bom lugar para esse tipo de informação. Os revisores
+não deveriam ter que vasculhar os arquivos das listas de discussão para se
+familiarizarem com o que foi dito na última vez; se você ajudá-los a começar
+com o pé direito, eles estarão de melhor humor quando revisitarem o seu código.
+
+E se você tentou fazer tudo certo e as coisas ainda não estão avançando? A
+maioria das divergências técnicas pode ser resolvida por meio de discussão,
+mas há momentos em que alguém simplesmente precisa tomar uma decisão. Se você
+acredita genuinamente que essa decisão está indo contra você de forma errada,
+você sempre pode tentar recorrer a uma instância superior. Até o momento em
+que este texto foi escrito, essa instância superior costuma ser Andrew Morton.
+Andrew goza de um enorme respeito na comunidade de desenvolvimento do kernel;
+ele frequentemente consegue destravar uma situação que parece desesperadoramente
+bloqueada. Recorrer a Andrew, no entanto, não deve ser feito de ânimo leve e nem
+antes que todas as outras alternativas tenham sido esgotadas. E tenha em mente,
+é claro, que ele também pode não concordar com você.
+
+O que acontece a seguir
+-----------------------
+
+Se um patch for considerado algo bom para ser adicionado ao kernel, e assim
+que a maioria dos problemas de revisão tiver sido resolvida, o próximo passo
+geralmente é a entrada na árvore de um mantenedor de subsistema. Como isso
+funciona varia de um subsistema para o outro; cada mantenedor tem sua própria
+maneira de fazer as coisas. Em particular, pode haver mais de uma árvore — uma,
+talvez, dedicada a patches planejados para a próxima janela de mesclagem
+(*merge window*), e outra para trabalhos de longo prazo.
+
+Para patches que se aplicam a áreas para quais não há uma árvore de subsistema
+óbvia (patches de gerenciamento de memória, por exemplo), a árvore padrão
+geralmente acaba sendo a *-mm*. Patches que afetam múltiplos subsistemas
+também podem acabar passando pela árvore *-mm*.
+
+A inclusão em uma árvore de subsistema pode trazer um nível mais alto de
+visibilidade para um patch. Agora, outros desenvolvedores que trabalham com
+aquela árvore receberão o patch por padrão. As árvores de subsistemas tipicamente
+alimentam a *linux-next* também, tornando seus conteúdos visíveis para a
+comunidade de desenvolvimento como um todo. Neste ponto, há uma boa chance de
+você receber mais comentários de um novo conjunto de revisores; esses
+comentários precisam ser respondidos da mesma forma que na rodada anterior.
+
+O que também pode acontecer neste ponto, dependendo da natureza do seu patch,
+é surgirem conflitos com o trabalho que está sendo feito por outros. No pior
+dos casos, conflitos pesados de patches podem fazer com que alguns trabalhos
+sejam deixados em segundo plano, para que os patches restantes possam ser
+ajustados e mesclados. Outras vezes, a resolução de conflitos envolverá trabalhar
+junto a outros desenvolvedores e, possivelmente, mover alguns patches entre
+árvores para garantir que tudo se aplique de forma limpa. Este trabalho pode ser
+árduo, mas console-se com uma vantagem: antes do surgimento da árvore *linux-next*,
+esses conflitos frequentemente só apareciam durante a janela de mesclagem e
+tinham que ser resolvidos às pressas. Agora eles podem ser resolvidos com calma,
+antes que a janela de mesclagem se abra.
+
+Um belo dia, se tudo correr bem, você fará login e verá que o seu patch foi
+mesclado ao kernel principal (*mainline*). Parabéns! No entanto, assim que a
+comemoração terminar (e você tiver se adicionado ao arquivo MAINTAINERS), vale
+a pena lembrar de um pequeno fato importante: o trabalho ainda não acabou. A
+mesclagem na árvore principal traz os seus próprios desafios.
+
+Para começar, a visibilidade do seu patch aumentou ainda mais. Pode haver
+uma nova rodada de comentários de desenvolvedores que não estavam cientes do
+patch antes. Pode ser tentador ignorá-los, já que não há mais nenhuma dúvida
+sobre a mesclagem do seu código. No entanto, resista a essa tentação; você
+ainda precisa ser receptivo aos desenvolvedores que tiverem dúvidas ou
+sugestões.
+
+Mais importante ainda: a inclusão na árvore principal coloca o seu código
+nas mãos de um grupo muito maior de testadores. Mesmo que você tenha contribuído
+com um driver para um hardware que ainda não está disponível, você se
+surpreenderá com a quantidade de pessoas que compilarão seu código em seus
+próprios kernels. E, logicamente, onde há testadores, haverá relatórios de
+erros (*bug reports*).
+
+O pior tipo de relatório de erro são as regressões (*regressions*). Se o seu
+patch causar uma regressão, você descobrirá uma quantidade desconfortável de
+olhos voltados para você; as regressões precisam ser corrigidas o mais rápido
+possível. Se você não estiver disposto ou for incapaz de corrigir a regressão
+(e ninguém mais fizer isso por você), seu patch quase certamente será removido
+durante o período de estabilização. Além de anular todo o trabalho que você teve
+para colocar seu patch na árvore principal, ter um patch removido como resultado
+da falha em corrigir uma regressão pode muito bem tornar mais difícil para você
+mesclar trabalhos no futuro.
+
+Depois que todas as regressões tiverem sido tratadas, pode haver outros erros
+comuns com os quais lidar. O período de estabilização é a sua melhor oportunidade
+para corrigir esses problemas e garantir que a estreia do seu código em um
+lançamento do kernel principal seja o mais sólida possível. Portanto, por favor,
+responda aos relatórios de erros e corrija os problemas, se for viável. É para
+isso que serve o período de estabilização; você pode começar a criar novos
+patches fantásticos assim que quaisquer problemas com os antigos tiverem sido
+resolvidos.
+
+E não se esqueça de que existem outros marcos que também podem gerar relatórios
+de erros: o próximo lançamento estável da árvore principal, o momento em que
+distribuidores proeminentes adotarem uma versão do kernel que contenha o seu
+patch, etc. Continuar respondendo a esses relatórios é uma questão de orgulho
+básico pelo seu trabalho. Se isso não for motivação suficiente, contudo, também
+vale a pena considerar que a comunidade de desenvolvimento se lembra dos
+desenvolvedores que perdem o interesse em seu próprio código após a mesclagem.
+A próxima vez que você enviar um patch, eles o avaliarão sob a suposição de
+que você não estará por perto para mantê-lo depois.
+
+
+Outras coisas que podem acontecer
+---------------------------------
+
+Um dia, você poderá abrir o seu cliente de e-mail e ver que alguém lhe enviou
+um patch para o seu código. Afinal, essa é uma das vantagens de ter o seu
+código disponível publicamente. Se você concordar com o patch, poderá encaminhá-lo
+para o mantenedor do subsistema (certifique-se de incluir uma linha ``From:``
+adequada para que a atribuição de autoria esteja correta e adicione a sua
+própria assinatura — *signoff*) ou enviar uma resposta com um ``Acked-by:``
+e deixar que o remetente original o envie para cima.
+
+Se você não concordar com o patch, envie uma resposta educada explicando o
+motivo. Se possível, diga ao autor quais alterações precisam ser feitas para
+que o patch seja aceitável para você. Existe uma certa resistência em mesclar
+patches que sofrem oposição do autor e mantenedor do código, mas isso tem limite.
+Se você for visto como alguém que está bloqueando um bom trabalho sem necessidade,
+esses patches eventualmente seguirão outro fluxo ao seu redor e entrarão na
+árvore principal de qualquer maneira. No kernel do Linux, ninguém tem poder de
+veto absoluto sobre nenhum código. Exceto, talvez, o Linus.
+
+Em ocasiões muito raras, você poderá ver algo completamente diferente: outro
+desenvolvedor envia uma solução diferente para o seu problema. Nesse ponto,
+as chances são de que um dos dois patches não seja mesclado, e o argumento
+"o meu chegou primeiro" não é considerado um argumento técnico convincente.
+Se o patch de outra pessoa deslocar o seu e entrar na árvore principal, existe
+realmente apenas uma maneira de responder: fique satisfeito pelo fato de o seu
+problema ter sido resolvido e siga adiante com o seu trabalho. Ter o próprio
+trabalho deixado de lado dessa maneira pode ser doloroso e desanimador, mas a
+comunidade se lembrará da sua reação muito depois de terem esquecido de quem
+foi o patch que realmente foi mesclado.

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

@@ -22,3 +22,4 @@ conhecimento profundo de programação de kernel para ser compreendida.
    3.Early-stage
    4.Coding
    5.Posting
+   6.Followthrough