He escrito sobre la gestión de un commitfest de PostgreSQL antes.
Durante el ciclo de desarrollo de PostgreSQL 13, lo hice de nuevo. Esta vez usé una estrategia diferente, principalmente porque sentí que había una acumulación excesiva de parches muy antiguos que no habían recibido suficiente atención. Entonces, aparte de las correcciones de errores (que siempre son casos especiales), me concentré en los parches que habían estado en la cola por más tiempo.
Una cosa que noté es que algunos parches no se habían actualizado por retroalimentación, o por bit-rotting, incluso después de repetidas insistencias de los administradores de commitfest anteriores. Se mueven de un commitfest a otro sin ninguna otra actividad. Algunos de ellos son de personas que han dejado atrás el desarrollo de PostgreSQL; otros pueden ser proyectos abandonados. En mi opinión, no tiene sentido mantenerlos si no sucede nada, así que los cerré y proporcioné una lista, para que otros puedan echar un vistazo y tomar posesión si así lo desean. (Una publicación de seguimiento contiene algunos más). Mi esperanza es que si alguien está interesado en esas características, recogerá los parches y los volverá a enviar después de abordar cualquier comentario y bit-rot.
Otra cosa que se está volviendo común es que muchos parches persisten con poca revisión o, a veces, incluso con una revisión sustancial, nunca llegan al punto en que un usuario los selecciona. En algunos de esos casos, mi enfoque fue presionar a personas específicas que pensé que podrían ayudar con la revisión; en otros casos, solo revisé los parches yo mismo. A veces, simplemente hacer una pregunta parece haber sido suficiente para involucrar a otros en la discusión, por lo que incluso si la contribución directa de uno es pequeña, tiene un efecto útil mayor.
También me inscribí como revisor/autor de algunos parches. Tuve un éxito moderado en eso, terminando con 24 confirmaciones y 10 entradas de commitfest marcadas como confirmadas... o alrededor del 25% del número total de entradas de commitfest confirmadas. No está mal, ¿eh?
En mi correo electrónico de informe de cierre, publiqué esta tabla:
| Estado | semana1 | semana2 | semana3 | semana4 | final |
| Necesita revisión | 165 | 138 | 116 | 118 | 0 |
| Esperando al autor | 30 | 44 | 51 | 44 | 0 |
| Listo para confirmar | 11 | 5 | 8 | 11 | 0 |
| Devuelto con comentarios | 1 | 4 | 5 | 5 | 28 |
| Movido al siguiente CF | 2 | 4 | 4 | 4 | 191 |
| Comprometido | 14 | 23 | 32 | 34 | 42 |
| Rechazado | 1 | 1 | 1 | 1 | 1 |
| Retirado | 4 | 9 | 11 | 11 | 12 |
Una cosa que vale la pena señalar es cómo "devuelto con comentarios" se mantuvo bastante bajo todo el tiempo y solo saltó al final, y por un recuento grande. Un ejercicio que sugiero que hagan los futuros CFM es cerrar de manera saludable los parches inactivos y bit-rot al final de su mandato, en lugar de mover dichos parches al siguiente commitfest. Esta última operación debe reservarse para los parches que han estado activos durante el CF, o los que aún se aplican, o los que han estado esperando a los autores recientemente. La otra cosa que vale la pena señalar es la cantidad de parches comprometidos... o más bien la lentitud con la que subió. Algunos autores estaban distraídos por ayudar con el lanzamiento de Postgres 12; otros estaban muy activos en parches que no lo estaban parte del compromiso. Espero que varios autores de confirmación presten más atención la próxima vez, y luego veremos un progreso real.
El robot commitfest de Thomas Munro es una herramienta invaluable; los autores de parches deberían prestar más atención a eso. Sería mucho mejor tener ese servicio integrado en la infraestructura de nuestra comunidad commitfest; Creo que solo requiere algunos tuits redondos.
Algunas cosas que me hubiera gustado tener:
- un pg_dump actualizado de los datos del commitfest, para consultas locales.
- Obtuve vertederos semanales preguntando a la persona adecuada y escribí algunas consultas toscas. Podríamos proporcionar los resultados de (versiones mejoradas de) tales consultas como informes en las aplicaciones, tal vez.
- También serían bienvenidos algunos filtros mejorados en la aplicación commitfest.
- El acto de mover parches en masa al próximo CF podría automatizarse mejor.
En general, este fue un mes muy satisfactorio y espero que haya sido valioso para el desarrollo de PostgreSQL. Estoy agradecido de que 2ndQuadrant me haya dado la oportunidad de pasar el mes haciendo esto... pero aun así, espero volver a mis funciones regulares.
