xref: /linux/Documentation/translations/pt_BR/process/6.Followthrough.rst (revision 72fdff1416e280e2baaa3cca69574defb998437e)

.. 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.