Si ha estado siguiendo el desarrollo de PostgreSQL durante los últimos años, probablemente haya escuchado el término administrador de commitfest unas pocas veces. Probablemente ya sepa qué es un commitfest, pero ¿por qué hay un administrador? Ya que pasé mucho tiempo el pasado mes de enero administrando uno, lo explicaré.
Parche aplicado durante el commitfest
En esencia, un commitfest de PostgreSQL es solo una colección de parches que esperan la integración en la base de código de PostgreSQL. El principio de funcionamiento de un commitfest es que cada parche que se ha enviado a pgsql-hackers debe ser revisado oportunamente; una vez revisado y revisado suficientes veces, el parche es candidato para su inclusión permanente en PostgreSQL por parte de un usuario.
En cuanto al flujo de trabajo del commitfest:cada nuevo parche comienza en el commitfest en el estado "necesita revisión"; se puede cerrar como "rechazado" (rompiendo el frágil corazón del autor), "comprometido" (haciendo el día, la semana o el mes del autor) o "devuelto con retroalimentación" (por lo que el autor necesita seguir adelante, sabiendo lo que hacer para mejorar el parche y resucitarlo en un futuro commitfest). También hay un estado de corta duración, "esperando al autor", que se usa para comentarios rápidos que se espera que resulten en una nueva versión del parche en unos días nuevamente como "necesita revisión". Mientras tengamos algunas cosas marcadas como "comprometidas" y los autores reciban buenos comentarios, las cosas seguirán su curso:PostgreSQL crece, evoluciona y madura para convertirse en la próxima "versión importante".
Hasta ahora todo bien.
¿Por qué necesitamos un gerente?
Administrar un evento de confirmación
El lector atento puede haber notado que hay tres grupos de personas involucradas en el proceso:autores de parches, revisores, confirmadores. Hay mucha superposición entre esos tres grupos, que es donde comienzan los problemas. Para hacer buenas revisiones a nivel de código, la gente necesita entender el código, y aquellos que lo hacen también están escribiendo sus propios parches. Por otro lado, los committers son solo revisores que se supone que tienen mejores habilidades para encontrar y solucionar "problemas" de código. Los autores también escriben sus propios parches todo el tiempo.
El problema es que si el autor de un parche continúa trabajando exclusivamente en sus propios parches, no tendrá tiempo para revisar o confirmar los parches de otras personas. Esto puede suceder fácilmente si reciben comentarios e inmediatamente trabajan en otra versión, lo que genera más comentarios; esto crea un bucle que puede durar mucho tiempo. En algún momento, lo justo es que el autor elimine el parche del commitfest y trabaje en revisar el parche de otra persona; pero debido a que todos creen que sus parches son muy importantes, esto rara vez sucede espontáneamente.
Ahí es donde el administrador del commitfest entra en escena. Una tarea es captar el interés de los hackers de pgsql para que revisen los parches. La mayoría de las veces, enviar correos electrónicos públicos al grupo es suficiente para que la gente lea, discuta, pruebe y piense en los parches. A menudo, los autores de parches necesitan que se les recuerde que deben mirar los parches de otras personas, no solo los suyos. La aplicación commitfest tiene una práctica interfaz de envío de correo electrónico que se puede usar para eso. Estas cosas normalmente son suficientes para crear una buena cantidad de revisiones cruzadas.
Hay una regla antigua, casi olvidada:si el autor de un parche no hace revisiones, sus parches pueden cerrarse desde el commitfest sin más consideración. Que yo sepa, esto nunca ha sucedido, lo que indica que, al menos hasta cierto punto, los autores de parches están siendo "buenos ciudadanos".
Por lo tanto, ya sea por persuasión o coerción, un administrador de commitfest puede hacer que las personas revisen los parches, lo que en su mayoría no ocurriría espontáneamente, excepto cuando los piratas informáticos ya están trabajando en cooperación.
Por otro lado, los autores de parches a veces dejan sus parches sin actualizaciones. Una posible respuesta es simplemente cerrarlos "devueltos con comentarios", pero la mayoría de las veces vale la pena empujar a un autor para que envíe una versión actualizada.
El administrador de commitfest también puede pasar mucho tiempo haciendo sus propias revisiones y, si tiene privilegios de confirmación, enviando parches.
Finalmente, es responsabilidad del administrador del commitfest asegurarse de que todos los parches estén cerrados cuando termine el commitfest, lo que normalmente debería ser un mes después de que comenzó. Para los parches que han recibido comentarios, a los que el autor ha respondido con otra versión, es justo "mover el parche al próximo commitfest":la promesa del commitfest (dar comentarios) se ha cumplido. Sin embargo, hacer eso con los parches que no han recibido ningún comentario es injusto. Cerrar commitfests se vuelve más difícil cuando eso sucede.
El festival de compromiso de enero de 2016
Este gráfico ilustra el commitfest de enero de 2016. Los datos son de los correos electrónicos de estado semanales que envié:inicio, semana 1, semana 2, semana 3, semana 4, final.
Puede ver que comenzamos con 85 en el estado "necesita revisión" o "listo para confirmar", lo que significa que estaban esperando que alguien que no sea el autor actuara. Una semana después, teníamos 71 parches en esos estados:eso significa que se procesaron 14 parches en una semana, lo cual no está mal porque, si se mantiene, esa tasa significa que toda la cola de parches terminará en solo 5 semanas más.
Sin embargo, durante esa primera semana cometí seis parches triviales. Se agotan bastante rápido y se espera que la tasa de confirmación disminuya. Afortunadamente, otros confirmadores trabajaron arduamente, y puede ver que la tasa de parches confirmados fue prácticamente constante durante todo el período. Probablemente sea posible lograr esto en todos los commitfests, suponiendo que se aplique la persuasión adecuada a los committers.
Es visible que el estado "devuelto con comentarios" solo apareció al final de la confirmación. Prácticamente continúa la tendencia vista en la línea "esperando al autor". En mi opinión, esto está bien. Algunas personas preferirían que ciertos parches se "arranquen" desde el principio, de modo que los esfuerzos se centren en los parches que realmente tienen posibilidades de entrar (un "triaje", por así decirlo). Yo mismo no estoy seguro de eso, así que no apliqué esa idea aquí.
Creo que este commitfest tuvo un éxito moderado en la confirmación de parches; el progreso en ese frente fue ciertamente visible, aunque no necesariamente enorme. También creo que fue un gran éxito al garantizar que todos los autores de parches tuvieran una buena cantidad de discusión sobre sus parches. Así que, por mi parte, estoy satisfecho con el trabajo realizado.
Consejos para futuros administradores de commitfest
Creo que tener actualizaciones de estado semanales da buenos resultados:les da a todos la impresión de que algo está pasando (y así es), motivando tanto a los revisores como a los que confirman la confirmación a hacer su trabajo.
Además, tomé el enfoque de enumerar algunos parches que necesitaban atención cada vez, no los mismos parches cada vez, sino que me enfoqué en un conjunto diferente cada vez, para asegurarme de que cada parche estancado tuviera una patada en alguna parte. Este es un trabajo sutil:sería más fácil enumerar todos los parches que necesitan atención, pero si lo hace, los ojos se nublarán ante las gigantescas listas y todo seguirá siendo ignorado.
Cualquier opinión que tenga sobre cómo se manejó el commitfest sería apreciada; envíeme un correo electrónico si no desea publicarlo públicamente como un comentario. Si cree que las cosas que hice no fueron efectivas o si tiene otras ideas sobre qué hacer, estoy dispuesto a escuchar. Puedo gestionar otras confirmaciones en el futuro, si los recursos lo permiten.
Finalmente, prepárate para el próximo commitfest de marzo de 2016. Será el último commitfest para 9.6 y estoy seguro de que habrá mucho que hacer para todos. ¡Feliz revisión del parche!
