Commitfest PostgreSQL: lo que revelaron en PGConf.dev 2026
En pocas palabras: El estudio de Jimmy Angelakos y Andreas Scherbaum, presentado el miércoles de PGConf.dev 2026 en Vancouver, analizó 6.678 patches y 899 autores desde diciembre de 2014: el 35,2% nunca se commiteó y el 42,6% de los autores mandó un solo patch en toda su historia. El dato que más importa para quien quiere aportar código no es ese: es que el 59,2% de los patches activos no tiene reviewer asignado, y ahí es donde se traba todo.
Jimmy Angelakos y Andreas Scherbaum presentaron en PGConf.dev 2026, el miércoles en Vancouver, un análisis cuantitativo sobre las métricas del commitfest PostgreSQL: sobre 6.678 patches y 899 autores relevados desde diciembre de 2014, el 35,2% de esos patches nunca llegó a commitearse.
El Commitfest es el sistema con el que el proyecto PostgreSQL organiza la revisión y el commit de patches enviados por la comunidad, funcionando en ciclos periódicos desde 2014. La charla “PostgreSQL Commitfest Metrics: A Quantitative Analysis”, dictada durante PGConf.dev 2026 en el campus Harbour Centre de Simon Fraser University, tomó 58 ediciones del commitfest para medir qué pasa con un patch desde que alguien lo manda hasta que se resuelve. Lo interesante del trabajo no es tanto el volumen de números —hay bastantes—, sino que casi todos apuntan en la misma dirección: el problema no está donde uno esperaría.
En este artículo:
- En 30 segundos
- ¿Qué es el Commitfest de PostgreSQL y cómo funciona?
- ¿Qué presentaron Angelakos y Scherbaum en PGConf.dev 2026?
- ¿Cuáles son las cuatro cifras clave del análisis y qué métricas usaron?
- ¿Por qué el volumen de patches creció pero el número de committers no?
- ¿Dónde ocurre realmente la espera en el proceso de revisión?
- ¿Qué limitaciones tiene esta medición según los propios autores?
- ¿Qué proponen Angelakos y Scherbaum para mejorar el proceso?
- Criterios para decidir cuándo insistir con un patch (y cuándo no)
- Errores comunes al interpretar estos datos
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- El estudio analizó 6.678 patches y 899 autores en 58 commitfests, desde diciembre 2014 hasta abril 2026.
- El 42,6% de los autores mandó exactamente un patch en toda su historia con el proyecto.
- El 35,2% de los patches nunca se commiteó: quedó como returned-with-feedback, withdrawn, rejected o rolling-over indefinidamente.
- El cuello de botella no está en el committer: el 59,2% de los 331 patches activos no tenía reviewer asignado.
- Patches y autores se duplicaron entre 2015 y 2025, pero la cantidad de committers activos se mantuvo estable en una mediana de 26,5 por año.
¿Qué es el Commitfest de PostgreSQL y cómo funciona?
El Commitfest agrupa los patches enviados por la comunidad en ciclos donde un reviewer los evalúa y, si pasan el control técnico, quedan marcados como “Ready for Committer” para que alguien con permisos de merge los integre. La aplicación que gestiona esto existe desde 2014. CFBot, el sistema de integración continua que corre los tests automáticos sobre cada patch, apareció recién en 2018, y ambos sistemas se integraron formalmente en 2025.
Eso explica algo que los propios autores marcan como limitación: durante años hubo un desfasaje entre lo que se discutía en la lista de correo pgsql-hackers y lo que quedaba registrado en el commitfest.
¿Qué presentaron Angelakos y Scherbaum en PGConf.dev 2026?
Angelakos, junto a Andreas “ads” Scherbaum de EDB, mostró un análisis de datos crudos sacados de la aplicación de Commitfest, sin recomendar soluciones. PGConf.dev 2026 se hizo del 19 al 22 de mayo en el Harbour Centre de Simon Fraser University, en el centro de Vancouver, y a diferencia de PGConf.EU o PostgreSQL@SCaLE, es la conferencia armada alrededor del trabajo de desarrollo, no de una audiencia.
El miércoles y el jueves corrió un commitfest presencial en una de las salas mientras se daban las charlas. Hubo horarios de consulta abierta con la comunidad. El viernes entero fue unconference, con agenda armada el mismo día según lo que proponían los asistentes.
Angelakos y Scherbaum fueron explícitos sobre qué no era la charla: no es una crítica a ningún contribuyente ni a ningún committer, y no afirma que algo esté roto. Es una observación, no un diagnóstico. Esa aclaración, hecha al arranque de la charla, no es un detalle menor: en un proyecto con 38 committers voluntarios en doce años, cualquier lectura de estos números que suene a reproche individual pierde de vista dónde está realmente la fricción.
¿Cuáles son las cuatro cifras clave del análisis y qué métricas usaron?
Las cuatro cifras que resumen el estado del proceso son estas: 42,6% de autores con un solo patch en su historial, 35,2% de patches que nunca se commitearon, 46 patches estancados dos años o más, y un patch abierto hace 3.750 días, más de diez años, sin commitear, rechazar ni retirar. Para evitar que unos pocos patches viejísimos distorsionen el panorama, los autores usaron medianas y percentiles en vez de promedios en todo el estudio.
- 42,6% de autores con un solo patch: casi la mitad de las 899 personas que alguna vez mandaron un patch nunca volvió a hacerlo.
- 35,2% de patches nunca commiteados: quedaron como returned-with-feedback, withdrawn, rejected o dando vueltas de commitfest en commitfest.
- 46 patches estancados dos años o más: ni avanzan ni se cierran formalmente.
- Un patch de 3.750 días abierto: más de diez años sin resolución de ningún tipo.
De los patches que sí se commitean, la mediana toma 80 días desde el envío. El percentil 90 sube a 256 días y el percentil 99 llega a 711 días, casi dos años.
Ejemplo hipotético (ilustrativo, no es un caso real)
Para que estos números se entiendan en términos concretos, pensemos en un caso inventado, con nombre ficticio: Lucía manda en enero su primer patch a PostgreSQL, una corrección menor al planner. Si nadie se anota como reviewer en las primeras semanas —algo que, según el estudio, le pasa al 59,2% de los patches activos—, el patch entra en la bolsa de “Needs review sin reviewer asignado”, donde la mediana de espera es de 54 días y el percentil 90 llega a 244 días. Si Lucía se cansa y no vuelve a insistir, su patch termina engrosando el 35,2% que nunca se commitea, y ella misma pasa a formar parte del 42,6% de autores que mandó un solo patch en toda su historia.
Ahora el mismo caso con otro final: si Lucía consigue que alguien se anote como reviewer en las primeras semanas y el patch pasa el control técnico, el tramo final es mucho más corto de lo que uno imaginaría: una vez que un patch llega a “Ready for Committer”, la mediana de espera hasta el merge es de apenas 3 días. La diferencia entre los dos finales no está en la calidad del código ni en la paciencia del committer. Está en si alguien se anotó como reviewer a tiempo. Este ejemplo es completamente hipotético, armado a partir de las medianas y percentiles reales del estudio, y no corresponde a ningún patch puntual del commitfest.
¿Por qué el volumen de patches creció pero el número de committers no?
Porque el lado que recibe patches se duplicó en diez años y el lado que puede mergearlos se quedó igual. En 2015 hubo 418 patches de 125 autores; en 2025, 885 patches de 272 autores. Ambas cifras casi se duplicaron, algo que en un proyecto sano es buena señal.
Lo que no se duplicó fue quién puede aprobar el resultado final. En doce años aparecen 38 committers distintos, y la mediana de gente que efectivamente comitea en un año dado es de 26,5. Es decir: de esos 38 committers habilitados a lo largo de la historia del proyecto, en un año típico solo cerca de 26 o 27 están activos mergeando código. No es una queja contra los committers, que dedican tiempo especializado de forma voluntaria. Es aritmética simple: si el lado de entrada se duplica y el de salida no, algo absorbe la diferencia, y lo que absorbe es el tiempo de espera.
¿Y quién vuelve a mandar patches con el tiempo? Cada vez menos gente. Del grupo que mandó su primer patch en 2015, el 73% volvió a hacerlo después; para 2024 ese número bajó al 37%. No hay un salto brusco, sino una caída sostenida: 55% en 2017, 48% en 2019, y un piso de 36-37% en 2023 y 2024. Mientras tanto, el trabajo se concentra arriba: los cinco committers más activos hacen el 55% de los commits, y los diez primeros, el 74%. Da la sensación de que el proyecto funciona con una base ancha de gente que entra, prueba, y no vuelve, sostenida por un núcleo muy chico que absorbe casi todo el mérito de decidir qué entra al código.
¿Dónde ocurre realmente la espera en el proceso de revisión?
La espera no ocurre al final de la cola, sino al principio: el 59,2% de los patches activos no tiene ningún reviewer asignado. La suposición inicial de Angelakos era que el cuello de botella estaría en “Ready for Committer”, con patches acumulándose a la espera de que alguien senior apretara el botón. Los datos dicen otra cosa, y es el punto más contraintuitivo de toda la charla.
| Etapa del patch | Mediana de espera | Percentil 90 | Caso más largo registrado |
|---|---|---|---|
| Ready for Committer | 3 días | 30 días | — |
| Needs review, sin reviewer asignado | 54 días | 244 días | 892 días |
De los 331 patches activos, 196 (el 59,2%) no tenían reviewer asignado. Mirando toda la historia del proyecto, el 72,1% de los patches en estado “Needs review” nunca tuvo reviewer asignado, y de los que sí tuvieron uno, el 72% consiguió exactamente un solo reviewer, nunca más. La mayoría de los patches no espera a un committer. Espera a que alguien los levante primero. Puesto así, el diagnóstico es casi lo contrario de lo que uno imaginaría: el problema no es la falta de gente con permisos de merge, es la falta de gente dispuesta a leer código ajeno antes de que llegue a ese punto.
¿Qué limitaciones tiene esta medición según los propios autores?
Los propios autores admiten que la aplicación de Commitfest no ve la mayor parte del trabajo real del proyecto. Solo alrededor del 17% de los commits de git entre 2021 y 2026 aparece en algún commitfest, y cerca del 80% de los patches se discute únicamente en la lista pgsql-hackers, fuera del radar de esta herramienta.
Tampoco existe un cruce sistemático entre el ID del commit, el hilo de la lista de correo y la entrada del commitfest, así que no hay forma de armar un rastro de auditoría completo entre esas tres capas. Vale la pena tenerlo presente antes de sacar conclusiones demasiado categóricas: los números que vimos hasta acá describen una parte visible del proceso, no el proceso entero.
¿Qué proponen Angelakos y Scherbaum para mejorar el proceso?
Proponen tratar el triage como una tarea con nombre propio, no como algo que pasa si a alguien le queda tiempo libre. La lectura de los autores es que la aplicación de Commitfest no tiene ningún camino de cierre corto de una decisión formal, lo que explica cómo termina existiendo un patch de diez años sin resolver.
Para dar contexto, compararon con otros proyectos open source. Ninguno de esos modelos aplica tal cual a PostgreSQL, pero conviene tenerlos ordenados uno al lado del otro para ver qué caminos ya probó otra gente:
| Proyecto | Qué hace distinto | En qué se apoya |
|---|---|---|
| Django | Paga el triage como trabajo | Dos Software Foundation Fellows dedicados a revisar y triagear |
| Rust | Onboarding activo | Compilador que orienta al autor, equipos de gobernanza, proceso RFC |
| Linux | Descentraliza la revisión | Miles de entradas en MAINTAINERS, un maintainer/reviewer por subsistema |
| Perl | Caso de advertencia, no de modelo | El desgaste cultural corrió a la siguiente generación de desarrolladores hacia Python |
La pregunta que dejaron planteada en Vancouver fue directa: qué cambios mejorarían la experiencia del contribuyente y bajarían las barreras de entrada sin resignar el estándar técnico del proyecto. Sus sugerencias apuntan a facilitar el cierre formal de un patch, hacer explícito el ruteo de reviewers y nombrar el triage como tarea concreta. Nada de eso está decidido todavía, y los propios autores lo dejaron como pregunta abierta a la comunidad, no como propuesta cerrada.
Criterios para decidir cuándo insistir con un patch (y cuándo no)
Tomando las medianas y percentiles del propio estudio, se puede armar una guía simple para quien esté siguiendo un patch propio en el commitfest:
- Si pasaron 54 días o más sin reviewer asignado: ya estás en la mediana exacta de espera del estudio. Es buen momento para postear explícitamente en pgsql-hackers pidiendo un reviewer, en vez de esperar a que aparezca solo.
- Si pasaron 244 días o más sin reviewer: estás en el percentil 90, el tramo largo de la cola. Conviene reconsiderar el enfoque: partir el patch en cambios más chicos, buscar un co-autor, o preguntar directamente en algún espacio de la comunidad, como los office hours que corrieron durante PGConf.dev 2026.
- Si tu patch ya llegó a “Ready for Committer”: no hace falta insistir ni preocuparse por la demora. Ese tramo tiene una mediana de apenas 3 días; no es ahí donde se traba el proceso según los datos.
- Si sos autor primerizo: el estudio muestra que la tasa de retorno después de un primer patch cayó del 73% al 37% en diez años. Conseguir algún tipo de respuesta temprana, aunque sea negativa, pesa más para que vuelvas a contribuir que la velocidad del commit final.
Errores comunes al interpretar estos datos
- Leer el 35,2% de patches no commiteados como fracaso técnico: ese número mezcla patches rechazados por razones válidas con patches abandonados por falta de reviewer. Son fenómenos distintos que la métrica agregada no separa.
- Culpar a los committers por el cuello de botella: los datos muestran lo contrario. El “Ready for Committer” se resuelve en una mediana de 3 días. El problema está antes, en la falta de reviewers voluntarios.
- Tomar el commitfest como espejo fiel de toda la actividad del proyecto: solo el 17% de los commits de git aparece ahí. Buena parte del trabajo real de PostgreSQL sucede en pgsql-hackers y nunca queda registrado en esta herramienta.
- Comparar sin ajustar por medianas: los propios autores evitaron promedios a propósito, porque un puñado de patches de diez años distorsiona cualquier cifra agregada. Repetir el análisis con promedios da un panorama falso.
Preguntas Frecuentes
¿Qué es el Commitfest de PostgreSQL y para qué sirve?
El Commitfest es el sistema formal con el que PostgreSQL organiza la revisión y el commit de patches enviados por la comunidad, en ciclos que corren desde 2014. Sirve para que cada aporte de código pase por un reviewer antes de llegar a manos de un committer con permisos de merge.
¿Cuánto tarda en promedio en aprobarse un patch en PostgreSQL?
La mediana es de 80 días desde el envío hasta el commit, según el análisis presentado en PGConf.dev 2026. El percentil 90 sube a 256 días, y el 1% de los casos más lentos tarda hasta 711 días, casi dos años.
¿Por qué hay tan pocos committers en PostgreSQL comparado con la cantidad de patches?
Porque el volumen de patches y autores se duplicó entre 2015 y 2025, mientras la cantidad de committers activos se mantuvo estable en una mediana de 26,5 por año, sobre un total de 38 committers distintos en doce años. El lado que recibe trabajo creció; el lado que lo aprueba, no.
¿Qué se presentó en PGConf.dev 2026 sobre métricas de contribución?
Jimmy Angelakos y Andreas Scherbaum presentaron “PostgreSQL Commitfest Metrics: A Quantitative Analysis” el miércoles de PGConf.dev 2026 en Vancouver, con datos de 58 commitfests, 6.678 patches y 899 autores desde diciembre de 2014 hasta abril de 2026.
¿Cómo puedo empezar a contribuir a PostgreSQL sin que mi patch quede abandonado?
Conseguir un reviewer temprano es el factor que más pesa: el 59,2% de los patches activos analizados no tenía ninguno asignado, y esos esperaban una mediana de 54 días. Buscar activamente a alguien de la comunidad que se sume como reviewer, en vez de esperar a que aparezca solo, es lo que marca la diferencia según los propios datos del estudio.
Conclusión
Lo que dejó PGConf.dev 2026 no es una acusación contra nadie, es un mapa de dónde se pierde el tiempo. El commitfest PostgreSQL en números muestra un proceso donde el volumen de trabajo se duplicó y la capacidad de mergearlo no, con la consecuencia lógica de que la espera se acumula antes de llegar al committer, no después.
Los datos no dicen qué solución tomar. Dicen dónde mirar: conseguir reviewers para el 59,2% de patches huérfanos pesa más que apurar al committer que ya tiene la cola despejada. Si algo queda claro después de repasar estas cifras es que el problema de PostgreSQL no es de gente sobrada de tiempo para mergear, es de gente que se anime a leer el código de otro antes de que llegue ahí.
