Un amigo me comentó hace unos días algo que resultaba difícil de creer: Etch había sido liberado con bugs release-critical. Como fuente me citaba el rastreador de bugs release-critical de Debian. Podemos comprobar cómo, efectivamente, en el momento de la liberación de Etch la gráfica no llega a los 0 bugs, como aparentemente sí ocurrió con Sarge.

Le respondí sorprendido que eso me extrañaba mucho, que seguro que había una explicación. Debian tiene como política que la versión stable se libera "cuando está lista", y no antes. Él estaba de acuerdo pero no encontraba el motivo. Intrigado por el misterio, he hecho algunas indagaciones.

Como esto no es una novela de suspense, os destripo el final: el asesino era Bill Ga... digooooo, que Etch se liberó con sólo 5 bugs clasificados como release-critical, muchos menos de los alrededor de 50 que parecen verse en la gráfica. Veremos a continuación cómo este número no es alarmante y tiene explicación.

La investigación comenzó, como no podía ser de otra forma, con una búsqueda en Google. Rápidamente se encuentra una reveladora conversación en una lista de correo, aunque en inglés. Son especialmente reveladores estos dos mensajes. En el hilo se incluye una referencia a Slashdot, que termina de aclarar el asunto.

Resumiendo para el público hispanohablante: la información de bugs.debian.org/release-critical tiene errores (¡bugs!), el más grave de los cuales es que por lo visto no tiene en cuenta el versionado de los paquetes a la hora de contar los bugs. Por ejemplo, un bug puede estar solucionado para una versión y siguientes de un paquete, pero no para el paquete en general, y aún así contabilizarse para Etch (o para la versión testing actual) independientemente de la versión que haya en la rama.

Eliminando esos "falsos positivos" siguen quedando bugs release-critical en el momento de la liberación de Etch, pero tienen un importante matiz: eran en su mayoría bugs de seguridad que se parchearían normalmente a través de security.debian.org. Aquí entra en conflicto la definición intuitiva de bug "release-critical" (Etch no puede salir mientras no se solucione esto) y la definición real (los bugs de importancia critical, grave o serious, o algunos casos especiales). Dado que los bugs de seguridad ocurren continuamente en un sistema operativo, no se consideró oportuno que retrasasen la liberación de Etch.

Existe no obstante un problema: eliminando esos bugs de seguridad, siguen quedando 5 bugs release-critical. Y Etch fue liberado sin que fuesen solucionados. Veo vuestras caras de sorpresa y las entiendo. ¡Debian sólo se libera cuando está lista! ¡Herejía, herejía! La explicación está una vez más en este mensaje: esos 5 bugs eran irreproducibles (es decir, no se puede determinar cuándo y cómo ocurren) y de severidad limitada. Arreglarlos podría haber retrasado Etch un mes o más.

Incluso con esos 5 bugs release-critical (que probablemente no deberían haber sido calificados como tales) la calidad de Etch fue considerada mayor que la de Sarge, y por eso se decidió su publicación.

Por mi parte, misterio resuelto.