Translates the section 6.followthrough.rst to Brazilian Portuguese for the process directory. Signed-off-by: Daniel Pereira --- .../pt_BR/process/6.Followthrough.rst | 220 ++++++++++++++++++ .../pt_BR/process/development-process.rst | 1 + 2 files changed, 221 insertions(+) create mode 100644 Documentation/translations/pt_BR/process/6.Followthrough.rst diff --git a/Documentation/translations/pt_BR/process/6.Followthrough.rst b/Documentation/translations/pt_BR/process/6.Followthrough.rst new file mode 100644 index 000000000..d6bdaa2cb --- /dev/null +++ b/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. diff --git a/Documentation/translations/pt_BR/process/development-process.rst b/Documentation/translations/pt_BR/process/development-process.rst index e9f04df62..ca86b481a 100644 --- a/Documentation/translations/pt_BR/process/development-process.rst +++ b/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 -- 2.47.3