Se você acompanha o desenvolvimento do PostgreSQL nos últimos anos, provavelmente já ouviu o termo commitfest manager algumas vezes. Você provavelmente já sabe o que é um commitfest, mas por que existe um gerente? Como passei muito tempo gerenciando um em janeiro passado, vou explicar.
Patch aplicado durante o commitfest
Em sua essência, um commitfest do PostgreSQL é apenas uma coleção de patches aguardando integração na base de código do PostgreSQL. O princípio de funcionamento de um commitfest é que cada patch enviado para pgsql-hackers deve ser revisto oportunamente; uma vez revisado e revisado várias vezes, o patch é candidato a inclusão permanente no PostgreSQL por um committer.
Quanto ao fluxo de trabalho do commitfest:cada novo patch começa a vida no commitfest no estado “necessita de revisão”; pode ser fechado como “rejeitado” (partindo o coração frágil do autor), “comprometido” (tornando o dia, semana ou mês do autor), ou “devolvido com feedback” (onde o autor precisa se manter, sabendo o que fazer para melhorar o patch e ressuscitá-lo em um commitfest futuro). Há também um status de curta duração, "aguardando autor", que é usado para feedback rápido que deve resultar em uma nova versão do patch em alguns dias novamente como "precisa de revisão". Enquanto tivermos algumas coisas marcadas como "comprometidas" e os autores receberem um bom feedback, as coisas estão caminhando:o PostgreSQL cresce, evolui e amadurece para se tornar o próximo "grande lançamento".
Até agora tudo bem.
Por que precisamos de um gerente?
Gerenciando um commitfest
O leitor atento deve ter notado que existem três grupos de pessoas envolvidas no processo:autores de patches, revisores, committers. Há muita sobreposição entre esses três grupos, que é onde os problemas começam. Para fazer uma boa revisão em nível de código, as pessoas precisam entender o código, e aquelas que entendem também estão escrevendo seus próprios patches. Por outro lado, os committers são apenas revisores que supostamente têm melhores habilidades para encontrar e corrigir “problemas” de código. Os committers também estão escrevendo seus próprios patches o tempo todo.
O problema é que se um autor de patch continuar trabalhando exclusivamente em seus próprios patches, ele não terá tempo para revisar ou confirmar os patches de outras pessoas. Isso pode acontecer facilmente se eles receberem feedback e trabalharem imediatamente em outra versão, resultando em mais feedback; isso cria um loop que pode durar muito tempo. Em algum momento, a coisa justa a fazer é o autor retirar o patch do commitfest e trabalhar na revisão do patch de outra pessoa; mas como todos acreditam que seus patches são muito importantes, isso raramente acontece espontaneamente.
É aí que o gerente do commitfest entra em cena. Uma tarefa é atrair o interesse dos hackers do pgsql para realmente revisar os patches. Na maioria das vezes, enviar e-mails públicos para o grupo é suficiente para que as pessoas leiam, discutam, testem, pensem em patches. Muitas vezes, os autores de patches precisam ser lembrados de que precisam examinar os patches de outras pessoas, não apenas os seus. O aplicativo commitfest tem uma interface de envio de e-mail prática que pode ser usada para isso. Essas coisas normalmente são suficientes para criar uma boa quantidade de revisão cruzada.
Existe uma regra antiga e quase esquecida:se um autor de patch não fizer revisões, seus patches podem ser fechados do commitfest sem maiores considerações. Que eu saiba, isso nunca aconteceu, o que significa que, pelo menos até certo ponto, os autores de patches estão sendo “bons cidadãos”.
Assim, seja por persuasão ou coerção, um gerente de commitfest pode fazer com que as pessoas revisem os patches, o que na maioria das vezes não ocorreria espontaneamente, exceto quando os hackers já estão trabalhando em cooperação.
Por outro lado, os autores de patches às vezes deixam seus patches sem atualizações. Uma resposta possível é simplesmente fechá-los “devolvidos com feedback”, mas na maioria das vezes vale a pena cutucar um autor para enviar uma versão atualizada.
O gerente do commitfest também pode gastar bastante tempo fazendo suas próprias revisões e, se tiver privilégios de commit, confirmando patches.
Finalmente, é responsabilidade do gerente do commitfest garantir que todos os patches sejam fechados quando o commitfest terminar, o que normalmente deve ocorrer um mês após o início. Para patches que receberam feedback, aos quais o autor respondeu com outra versão, é justo “mover o patch para o próximo commitfest”:a promessa do commitfest (dar feedback) foi mantida. No entanto, fazer isso com patches que não receberam nenhum feedback é injusto. Fechar commitfests se torna mais difícil quando isso acontece.
O commitfest de janeiro de 2016
Este gráfico ilustra o commitfest de janeiro de 2016. Os dados são dos e-mails de status semanais que enviei:início, semana 1, semana 2, semana 3, semana 4, final.
Você pode ver que começamos com 85 no status “necessita de revisão” ou “pronto para committer”, o que significa que eles estavam esperando alguém que não fosse o autor para agir. Uma semana depois, estávamos com 71 patches nesses status:isso significa que 14 patches foram processados em uma semana, o que não é ruim porque, se mantido, essa taxa significava que toda a fila de patches terminaria em apenas mais 5 semanas.
No entanto, durante essa primeira semana eu cometi seis patches triviais. Eles se esgotam rapidamente e a taxa de confirmação deve diminuir. Felizmente, outros committers estavam trabalhando duro, e você pode ver que a taxa de patches comprometidos foi praticamente constante durante todo o período. Provavelmente é possível conseguir isso em todos os commitfests, assumindo que a persuasão apropriada é aplicada aos committers.
É visível que o status “devolvido com feedback” só apareceu no final do commitfest. Ele praticamente continua a tendência vista na linha “aguardando o autor”. Na minha opinião, isso está bem. Algumas pessoas preferem que certos patches sejam “iniciados” logo no início, para que os esforços sejam focados nos patches que realmente têm chance de entrar (uma “triagem”, se você preferir). Não tenho certeza sobre isso, então não apliquei essa ideia aqui.
Eu acho que este commitfest foi moderadamente bem sucedido em fazer com que os patches fossem confirmados; o progresso nessa frente foi certamente visível, se não necessariamente enorme. Eu também acho que foi um enorme sucesso em garantir que todos os autores de patches tivessem uma boa quantidade de discussão sobre seus patches. Então, de minha parte, estou satisfeito com o trabalho realizado.
Conselhos para futuros gerentes de commitfest
Eu acho que ter atualizações de status semanais dá bons resultados:dá a todos a impressão de que algo está acontecendo (o que está), motivando tanto os revisores quanto os committers a fazerem seus trabalhos.
Além disso, adotei a abordagem de listar alguns patches que precisavam de atenção a cada vez - não os mesmos patches todas as vezes, mas concentrei-me em um conjunto diferente a cada vez, para garantir que cada patch parado tivesse um chute em algum lugar. Este é um trabalho sutil:seria mais fácil apenas listar todos os patches que precisam de atenção, mas se você fizer isso, os olhos ficam vidrados em listas gigantescas e tudo continua a ser ignorado.
Quaisquer opiniões que você tenha sobre como o commitfest foi gerenciado serão apreciadas; por favor, envie-me um e-mail se você não quiser publicá-lo publicamente como um comentário. Se você acha que as coisas que fiz foram ineficazes, ou se você tem outras ideias sobre o que fazer, estou disposto a ouvir. Eu posso gerenciar outros commitfests no futuro, se os recursos permitirem.
Finalmente, prepare-se para o próximo commitfest de março de 2016. Será o commitfest final para o 9.6 e tenho certeza de que haverá muito o que fazer para todos. Boa revisão de patches!
