Re: ¿Como anda Debian Sid?
On Thu, Nov 13, 2008 at 12:26:24PM -0300, Blu wrote:
> On Thu, Nov 13, 2008 at 04:06:45PM +0100, Marc Aymerich wrote:
> > Entonces la cuestión está en si el paso de paquetes de experimental a
> > Sid, cuando la liberación de lenny, será tan desastroso como para
> > dejar a Sid 'in-usable' o por el contrario, la cantidad de bugs en los
> > paquetes de experimental es perfectamente tolerable. ¿Que opinais los
> > que habeis 'vivido' esto cuando la liberación de etch?
>
> Me parece que te equivocas. Sid nunca deja de recibir paquetes de
> experimental. Es testing el que deja de recibir paquetes de Sid durante el
> periodo de congelamiento, y es testing el que recibe el shock de la
> avalancha de paquetes desde Sid cuando se produce la liberación de una
> versión estable.
Cierto con un pequeño detalle: Mientras estamos en esta etapa de estabilización,
muchos mantenedores se abstienen de hacer cambios importantes en sid. Esto es
porque tener cambios en sid que no van a migrar a testing impide usar sid para
enviar cambios que sí necesitan pasar. Ejemplo para ser más claro:
El paquete super-mail-reader tiene la versión 2.2 en testing. Upstream libera
la versión 3.0 con soporte para ver attachments flash en el mismo lector. Si el
mantenedor sube esa versión a sid, el equipo encargado de la liberación de lenny
*no* va a permitirle migrar, por que es un cambio muy fuerte (requiere que migre
tambien la nueva versión de gnash, pero eso causa incompatibilidades con
iceweasel, que no se puede actualizar por que evolution ...) Así que la versión
3.0 se queda atorada en sid esperando que salga lenny. Pero 3 días después se
descubre que 2.2 tiene un grave problema de seguridad, rápidamente corregido
en 2.2.1 y en 3.1. El mantenedor no puede usar 3.1, por que igual se quedaría
atorado, pero tampoco puede subir 2.2.1 a sid, por que esa es una versión menor
que la que ya está.
Claro que hay forma de resolver esto, lo que hay que hacer es subir 2.2.1 a
testing-proposed-updates. Pero esta es una solución mal vista, por que es más
trabajo para el mantenedor, para el equipo de liberación, para el de seguridad.
Además, los paquetes que pasan por ahí reciben menos exposición al público (y
menos revisión de calidad, por tanto) que los que pasan por sid, lo cual nos
expone a la necesidad de después subir 2.2.1.1 para corregir otro pequeño problema,
etc, etc.
Resultado: Casi todos los mantenedores se abstienen de hacer cambios no
indispensables en sid mientras testing está congelado, y en vez de eso los
mantienen en repos privados o ne experimental. En cuanto testing es liberado,
mucha gente tiene meses de cambios "en espera" que son enviados rápidamente a
sid. Sí suele quedar particularmente inestable por un rato, la verdad.
Reply to: