PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Gerenciando outro PostgreSQL Commitfest


Já escrevi sobre como gerenciar um commitfest do PostgreSQL antes.

Durante o ciclo de desenvolvimento do PostgreSQL 13, fiz isso de novo. Desta vez, usei uma estratégia diferente, principalmente porque senti que havia um acúmulo excessivo de manchas muito antigas que receberam atenção insuficiente. Então, além de correções de bugs (que são sempre casos especiais), concentrei-me em patches que estavam na fila há mais tempo.

Uma coisa que notei é que alguns patches não foram atualizados por feedback, ou por bit-rotting, mesmo após repetidas provocações de gerentes de commitfest anteriores. Eles são movidos de um commitfest para outro sem nenhuma outra atividade. Algumas delas são de pessoas que deixaram o desenvolvimento do PostgreSQL; outros podem ser projetos abandonados. Na minha opinião, não faz sentido mantê-los por perto se nada estiver acontecendo, então eu os fechei e forneci uma lista, para que outros possam dar uma olhada e se apropriar, se assim o desejarem. (Um post de acompanhamento contém um pouco mais). Minha esperança é que, se alguém estiver interessado nesses recursos, eles peguem os patches e reenviem depois de resolver qualquer feedback e bit-rot.

Outra coisa que está se tornando comum é que muitos patches permanecem com pouca revisão – ou às vezes mesmo com revisão substancial, eles nunca chegam ao ponto em que um committer os pega. Em alguns desses casos, minha abordagem foi estimular pessoas específicas que eu achava que poderiam ajudar na revisão; em outros casos, eu mesmo revi os patches. Às vezes, simplesmente fazer uma pergunta parece ter sido suficiente para envolver os outros na discussão; portanto, mesmo que a contribuição direta de alguém seja pequena, ela tem um efeito útil maior.

Eu também me inscrevi como revisor/commissor de alguns patches. Eu tive um sucesso moderado nisso, terminando com 24 commits e 10 entradas de commitfest marcadas como confirmadas... ou cerca de 25% do número total de entradas de commitfest confirmadas. Nada mal, hein?

No meu e-mail de relatório de encerramento, postei esta tabela:
Status semana1 semana2 semana3 semana 4 final
Precisa de revisão 165 138 116 118 0
Aguardando Autor 30 44 51 44 0
Pronto para o Committer 11 5 8 11 0
Devolvido com feedback 1 4 5 5 28
Movido para o próximo CF 2 4 4 4 191
Comprometido 14 23 32 34 42
Rejeitado 1 1 1 1 1
Retirado 4 9 11 11 12

Uma coisa que vale a pena notar é como “devolvido com feedback” permaneceu bem baixo o tempo todo e só pulou no final, e por uma contagem grande. Um exercício que sugiro que os futuros CFMs façam é fechar de forma saudável os patches inativos e bit-rot no final de seu mandato, em vez de mover esses patches para o próximo commitfest. A última operação deve ser reservada para patches que estiveram ativos durante o CF, ou aqueles que ainda se aplicam, ou aqueles que estão aguardando os autores apenas recentemente. A outra coisa que vale a pena notar é o número de patches comprometidos ... ou melhor, quão lentamente ele subiu. Alguns committers foram distraídos por ajudando com o lançamento do Postgres 12; outros eram muito ativos em patches que não eram parte do commitfest. Espero que vários committers prestem mais atenção na próxima vez, e então veremos algum progresso real.

O bot commitfest de Thomas Munro é uma ferramenta inestimável; os autores de patches devem prestar mais atenção a isso. Seria muito melhor ter esse serviço integrado à nossa infraestrutura de commitfest da comunidade; Acho que isso requer apenas alguns ternos redondos.

Algumas coisas que eu gostaria de ter:
  • um pg_dump atualizado dos dados do commitfest, para consulta local.
  • Recebi despejos semanalmente perguntando à pessoa certa e escrevi algumas perguntas grosseiras. Poderíamos fornecer os resultados de (versões aprimoradas) de consultas como relatórios nos aplicativos, talvez.
  • Algumas filtragens aprimoradas no aplicativo commitfest também seriam bem-vindas.
  • O ato de mover patches em massa para o próximo CF poderia ser mais automatizado.

Em suma, este foi um mês muito satisfatório e espero que tenha sido valioso para o desenvolvimento do PostgreSQL. Estou grato que o 2ndQuadrant me deu a oportunidade de passar o mês fazendo isso... mas mesmo assim, estou ansioso para voltar às minhas funções normais.