Postgres cuadruplica los mensajes en su lista de desarrollo y dobla los commits

El desarrollo de Postgres lleva engordando desde 1998, cuando arranca el archivo de su lista de correo, y un análisis publicado esta semana pone cifras a ese crecimiento. La lista pgsql-hackers, donde se envían y discuten los parches, ha pasado de unos 25 mensajes diarios en sus inicios a unos 100 hoy, con picos de 200. El repositorio git va por unos 50 commits semanales, frente a los 25 que se hacían en 2010.

Una lista cada vez más difícil de seguir

Los picos de 200 mensajes diarios no son aleatorios: caen siempre en marzo, justo antes del cierre de funcionalidades de la siguiente versión mayor. Es el momento en que más gente tiene prisa por colar sus parches. El autor reconoce que la consecuencia práctica es que seguir todas las discusiones al detalle se ha vuelto casi imposible, y de ahí la importancia de elegir bien el asunto de un hilo para que los demás decidan rápido si les interesa.

El volumen también ha cambiado. El tamaño total por día se mantuvo plano hasta 2009, cuando se dobló de 100 kB a 200 kB, y a partir de 2016 subió de forma gradual hasta unos 2 MB diarios. Ese segundo salto se ve más claro si se descuentan los adjuntos. El autor lo cruza con dos hitos: el concepto de commitfest nació en 2008 y la primera aplicación para gestionarlo se desplegó en 2015, justo antes de cada cambio. No lo da por demostrado y avisa de que puede ser casualidad.

Los adjuntos, que en la práctica son casi siempre parches, también han crecido: de 10 kB por mensaje a unos 80 kB. Y el porcentaje de mensajes con al menos un archivo adjunto pasó del 5% en 2008 al 25% actual.

Commits

Las estadísticas del repositorio van por semanas para evitar el ruido diario. El número de commits sube de forma lenta pero constante, y va en línea con el de personas con permiso de confirmación, que también se ha doblado entre 2010 y hoy.

Hay un detalle que no cuadra del todo: hasta principios de 2008 el ritmo se mantuvo, y ahí cayó en picado. El autor baraja dos explicaciones. La primera es la llegada del commitfest, cuyo primer ciclo encaja casi perfectamente con el desplome. La segunda, la migración de CVS a git, pero esa ocurrió en 2010, así que no cuadra. Se queda con la primera, sin descartar que sea la diferencia entre ambos sistemas de control de versiones.

Sobre la complejidad de los parches, hasta 2010 la mayoría tenía una o dos partes. Hoy el promedio es de 1,6, aunque el 90% sigue enviándose de una pieza y el 99% no pasa de diez. Hay una cola larga de parches enormes: el mayor de los datos llegó con 76 partes.

Para quien mantiene Postgres en producción, lo útil de este ejercicio es que acota una intuición: el proyecto crece al mismo ritmo que su base de colaboradores, y esa escala tiene un coste. La discusión se ha vuelto un caudal que ya nadie puede leer entero, y eso empuja a reorganizar cómo se revisa el trabajo. Queda por ver si el commitfest y las herramientas que lo acompañan siguen bastando, o si el cuello de botella se traslada a la revisión.