6. 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).
6.1. 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ê.
6.2. 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.
6.3. 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.