1.. SPDX-License-Identifier: GPL-2.0 2 3Acompanhamento 4============== 5 6Neste ponto, você seguiu as diretrizes apresentadas até aqui e, com a 7adição de suas próprias habilidades de engenharia, enviou uma série perfeita 8de patches. Um dos maiores erros que até mesmo desenvolvedores experientes 9do kernel podem cometer é concluir que o seu trabalho agora está concluído. 10Na verdade, o envio de patches indica uma transição para a próxima etapa 11do processo, possivelmente com uma quantidade considerável de trabalho 12ainda por fazer. 13 14É raro um patch ser tão bom em seu primeiro envio que não haja margem para 15melhorias. O processo de desenvolvimento do kernel reconhece esse fato e, 16como resultado, é fortemente orientado para o aprimoramento do código 17enviado. Espera-se que você, como autor desse código, trabalhe junto à 18comunidade do kernel para garantir que seu código esteja de acordo com os 19padrões de qualidade do kernel. A falha em participar desse processo muito 20provavelmente impedirá a inclusão de seus patches na árvore principal 21(*mainline*). 22 23 24Trabalhando com revisores 25------------------------- 26 27Um patch de qualquer relevância resultará em uma série de comentários de outros 28desenvolvedores à medida que eles revisam o código. Trabalhar com revisores 29pode ser, para muitos desenvolvedores, a parte mais intimidadora do processo 30de desenvolvimento do kernel. No entanto, a vida pode se tornar muito mais 31fácil se você mantiver algumas coisas em mente: 32 33* Se você explicou bem o seu patch, os revisores entenderão o seu valor 34 e o porquê de você ter tido o trabalho de escrevê-lo. Contudo, esse valor 35 não os impedirá de fazer uma pergunta fundamental: como será manter um 36 kernel com este código inserido nele daqui a cinco ou dez anos? Muitas das 37 mudanças que podem lhe pedir para fazer — desde ajustes de estilo de código 38 até reescritas substanciais — vêm do entendimento de que o Linux ainda estará 39 por aqui e sob desenvolvimento daqui a uma década. 40 41* A revisão de código é um trabalho árduo e uma ocupação relativamente 42 ingrata; as pessoas lembram quem escreveu o código do kernel, mas há pouca 43 fama duradoura para aqueles que o revisaram. Portanto, os revisores podem 44 ficar ranzinzas, especialmente quando veem os mesmos erros sendo cometidos 45 repetidamente. Se você receber uma revisão que pareça irritada, insultuosa 46 ou abertamente ofensiva, resista ao impulso de responder à altura. A revisão 47 de código diz respeito ao código, não às pessoas, e os revisores de código 48 não estão atacando você pessoalmente. 49 50* Da mesma forma, os revisores de código não estão tentando promover os 51 interesses de seus empregadores em detrimento dos seus. Os desenvolvedores 52 do kernel geralmente esperam continuar trabalhando no kernel daqui a muitos 53 anos, mas entendem que seu empregador pode mudar. Quase sem exceção, eles 54 estão verdadeiramente trabalhando em prol da criação do melhor kernel possível; 55 eles não estão tentando causar desconforto aos concorrentes de seus empregadores. 56 57* Esteja preparado para solicitações aparentemente tolas de mudanças no estilo 58 de codificação e pedidos para refatorar parte do seu código em seções 59 compartilhadas do kernel. Uma das funções dos mantenedores é manter as coisas 60 com a mesma aparência. Às vezes, isso significa que aquele truque inteligente 61 (*clever hack*) em seu driver para contornar um problema 62 63Note que você não precisa concordar com todas as mudanças sugeridas pelos 64revisores. Se você acredita que o revisor entendeu mal o seu código, explique 65o que realmente está acontecendo. Se tiver uma objeção técnica a uma mudança 66sugerida, descreva-a e justifique a sua solução para o problema. Se as suas 67explicações fizerem sentido, o revisor as aceitará. Contudo, caso a sua 68explicação não seja persuasiva — especialmente se outros começarem a concordar 69com o revisor —, reserve um tempo para repensar as coisas. Pode ser fácil ficar 70ceguificado por sua própria solução para um problema, a ponto de não perceber 71que algo está fundamentalmente errado ou que, talvez, você não esteja sequer 72resolvendo o problema certo. 73 74Andrew Morton sugeriu que todo comentário de revisão que não resulte em uma 75alteração de código deveria, em vez disso, resultar em um comentário adicional 76no próprio código; isso pode ajudar os futuros revisores a evitar as dúvidas 77que surgiram da primeira vez. 78 79Um erro fatal é ignorar os comentários de revisão na esperança de que eles 80desapareçam. Eles não vão desaparecer. Se você reenviar o código sem ter 81respondido aos comentários que recebeu da vez anterior, é provável que descubra 82que os seus patches não vão a lugar nenhum. 83 84Por falar em reenviar código: tenha em mente que os revisores não vão se 85lembrar de todos os detalhes do código que você enviou da última vez. Portanto, 86é sempre uma boa ideia lembrar os revisores dos problemas levantados 87anteriormente e de como você lidou com eles; o registro de alterações 88(*changelog*) do patch é um bom lugar para esse tipo de informação. Os revisores 89não deveriam ter que vasculhar os arquivos das listas de discussão para se 90familiarizarem com o que foi dito na última vez; se você ajudá-los a começar 91com o pé direito, eles estarão de melhor humor quando revisitarem o seu código. 92 93E se você tentou fazer tudo certo e as coisas ainda não estão avançando? A 94maioria das divergências técnicas pode ser resolvida por meio de discussão, 95mas há momentos em que alguém simplesmente precisa tomar uma decisão. Se você 96acredita genuinamente que essa decisão está indo contra você de forma errada, 97você sempre pode tentar recorrer a uma instância superior. Até o momento em 98que este texto foi escrito, essa instância superior costuma ser Andrew Morton. 99Andrew goza de um enorme respeito na comunidade de desenvolvimento do kernel; 100ele frequentemente consegue destravar uma situação que parece desesperadoramente 101bloqueada. Recorrer a Andrew, no entanto, não deve ser feito de ânimo leve e nem 102antes que todas as outras alternativas tenham sido esgotadas. E tenha em mente, 103é claro, que ele também pode não concordar com você. 104 105O que acontece a seguir 106----------------------- 107 108Se um patch for considerado algo bom para ser adicionado ao kernel, e assim 109que a maioria dos problemas de revisão tiver sido resolvida, o próximo passo 110geralmente é a entrada na árvore de um mantenedor de subsistema. Como isso 111funciona varia de um subsistema para o outro; cada mantenedor tem sua própria 112maneira de fazer as coisas. Em particular, pode haver mais de uma árvore — uma, 113talvez, dedicada a patches planejados para a próxima janela de mesclagem 114(*merge window*), e outra para trabalhos de longo prazo. 115 116Para patches que se aplicam a áreas para quais não há uma árvore de subsistema 117óbvia (patches de gerenciamento de memória, por exemplo), a árvore padrão 118geralmente acaba sendo a *-mm*. Patches que afetam múltiplos subsistemas 119também podem acabar passando pela árvore *-mm*. 120 121A inclusão em uma árvore de subsistema pode trazer um nível mais alto de 122visibilidade para um patch. Agora, outros desenvolvedores que trabalham com 123aquela árvore receberão o patch por padrão. As árvores de subsistemas tipicamente 124alimentam a *linux-next* também, tornando seus conteúdos visíveis para a 125comunidade de desenvolvimento como um todo. Neste ponto, há uma boa chance de 126você receber mais comentários de um novo conjunto de revisores; esses 127comentários precisam ser respondidos da mesma forma que na rodada anterior. 128 129O que também pode acontecer neste ponto, dependendo da natureza do seu patch, 130é surgirem conflitos com o trabalho que está sendo feito por outros. No pior 131dos casos, conflitos pesados de patches podem fazer com que alguns trabalhos 132sejam deixados em segundo plano, para que os patches restantes possam ser 133ajustados e mesclados. Outras vezes, a resolução de conflitos envolverá trabalhar 134junto a outros desenvolvedores e, possivelmente, mover alguns patches entre 135árvores para garantir que tudo se aplique de forma limpa. Este trabalho pode ser 136árduo, mas console-se com uma vantagem: antes do surgimento da árvore *linux-next*, 137esses conflitos frequentemente só apareciam durante a janela de mesclagem e 138tinham que ser resolvidos às pressas. Agora eles podem ser resolvidos com calma, 139antes que a janela de mesclagem se abra. 140 141Um belo dia, se tudo correr bem, você fará login e verá que o seu patch foi 142mesclado ao kernel principal (*mainline*). Parabéns! No entanto, assim que a 143comemoração terminar (e você tiver se adicionado ao arquivo MAINTAINERS), vale 144a pena lembrar de um pequeno fato importante: o trabalho ainda não acabou. A 145mesclagem na árvore principal traz os seus próprios desafios. 146 147Para começar, a visibilidade do seu patch aumentou ainda mais. Pode haver 148uma nova rodada de comentários de desenvolvedores que não estavam cientes do 149patch antes. Pode ser tentador ignorá-los, já que não há mais nenhuma dúvida 150sobre a mesclagem do seu código. No entanto, resista a essa tentação; você 151ainda precisa ser receptivo aos desenvolvedores que tiverem dúvidas ou 152sugestões. 153 154Mais importante ainda: a inclusão na árvore principal coloca o seu código 155nas mãos de um grupo muito maior de testadores. Mesmo que você tenha contribuído 156com um driver para um hardware que ainda não está disponível, você se 157surpreenderá com a quantidade de pessoas que compilarão seu código em seus 158próprios kernels. E, logicamente, onde há testadores, haverá relatórios de 159erros (*bug reports*). 160 161O pior tipo de relatório de erro são as regressões (*regressions*). Se o seu 162patch causar uma regressão, você descobrirá uma quantidade desconfortável de 163olhos voltados para você; as regressões precisam ser corrigidas o mais rápido 164possível. Se você não estiver disposto ou for incapaz de corrigir a regressão 165(e ninguém mais fizer isso por você), seu patch quase certamente será removido 166durante o período de estabilização. Além de anular todo o trabalho que você teve 167para colocar seu patch na árvore principal, ter um patch removido como resultado 168da falha em corrigir uma regressão pode muito bem tornar mais difícil para você 169mesclar trabalhos no futuro. 170 171Depois que todas as regressões tiverem sido tratadas, pode haver outros erros 172comuns com os quais lidar. O período de estabilização é a sua melhor oportunidade 173para corrigir esses problemas e garantir que a estreia do seu código em um 174lançamento do kernel principal seja o mais sólida possível. Portanto, por favor, 175responda aos relatórios de erros e corrija os problemas, se for viável. É para 176isso que serve o período de estabilização; você pode começar a criar novos 177patches fantásticos assim que quaisquer problemas com os antigos tiverem sido 178resolvidos. 179 180E não se esqueça de que existem outros marcos que também podem gerar relatórios 181de erros: o próximo lançamento estável da árvore principal, o momento em que 182distribuidores proeminentes adotarem uma versão do kernel que contenha o seu 183patch, etc. Continuar respondendo a esses relatórios é uma questão de orgulho 184básico pelo seu trabalho. Se isso não for motivação suficiente, contudo, também 185vale a pena considerar que a comunidade de desenvolvimento se lembra dos 186desenvolvedores que perdem o interesse em seu próprio código após a mesclagem. 187A próxima vez que você enviar um patch, eles o avaliarão sob a suposição de 188que você não estará por perto para mantê-lo depois. 189 190 191Outras coisas que podem acontecer 192--------------------------------- 193 194Um dia, você poderá abrir o seu cliente de e-mail e ver que alguém lhe enviou 195um patch para o seu código. Afinal, essa é uma das vantagens de ter o seu 196código disponível publicamente. Se você concordar com o patch, poderá encaminhá-lo 197para o mantenedor do subsistema (certifique-se de incluir uma linha ``From:`` 198adequada para que a atribuição de autoria esteja correta e adicione a sua 199própria assinatura — *signoff*) ou enviar uma resposta com um ``Acked-by:`` 200e deixar que o remetente original o envie para cima. 201 202Se você não concordar com o patch, envie uma resposta educada explicando o 203motivo. Se possível, diga ao autor quais alterações precisam ser feitas para 204que o patch seja aceitável para você. Existe uma certa resistência em mesclar 205patches que sofrem oposição do autor e mantenedor do código, mas isso tem limite. 206Se você for visto como alguém que está bloqueando um bom trabalho sem necessidade, 207esses patches eventualmente seguirão outro fluxo ao seu redor e entrarão na 208árvore principal de qualquer maneira. No kernel do Linux, ninguém tem poder de 209veto absoluto sobre nenhum código. Exceto, talvez, o Linus. 210 211Em ocasiões muito raras, você poderá ver algo completamente diferente: outro 212desenvolvedor envia uma solução diferente para o seu problema. Nesse ponto, 213as chances são de que um dos dois patches não seja mesclado, e o argumento 214"o meu chegou primeiro" não é considerado um argumento técnico convincente. 215Se o patch de outra pessoa deslocar o seu e entrar na árvore principal, existe 216realmente apenas uma maneira de responder: fique satisfeito pelo fato de o seu 217problema ter sido resolvido e siga adiante com o seu trabalho. Ter o próprio 218trabalho deixado de lado dessa maneira pode ser doloroso e desanimador, mas a 219comunidade se lembrará da sua reação muito depois de terem esquecido de quem 220foi o patch que realmente foi mesclado. 221