On Sun, Jan 04, 2004 at 11:33:33PM +0100, Sergio Talens-Oliag wrote:
>
> > Es más, llega el momento EMHO de, plantear un giro al sistema de
> > estabilización de Debian. ¿No sería conveniente agilizarlo?, ¿no es
> > demasiado monolítico?, ¿no sería planteable tomar ejemplo de BSD?. Dos
> > planteamientos sería muy interesantes de analizar: estabilizaciones
> > ágiles y mantenimiento "duro" de una base del SO y "suave" para el
> > equivalente a los ports de BSD. Tenemos la infraestructura ya creada
> > mediante los packages pools, no es complejo y simplificaría/ordenaría la
> > vida del proyecto y su relación con proyectos externos.
>
> Estoy de acuerdo, creo que a todos nos gustaría que el 'cuando esté
> listo' fuera más rápido, aunque no tengo claro si el esquema que
> propones funcionaría bien. De entrada el punto que veo más conflictivo
> es decidir qué entra en la parte "base" y como se gestiona la
> estabilización "suave" del resto de paquetes.
Essential e Important? es decir, lo que acaba en un sistema debian tras la
instsalacion del sistem sin dselect ni tasksel. Ni mas ni menos. Si acaso los
paquetes de pcmcia y alguna cosa mas. Para cada arquitectura su base.
Naturalmente con sus -dev.
El resto se puede integrar en paquetes o series (qt por ejemplo puede ser una
serie de grado inferior a kde, para poder congelar qt un mes antes de kde).
Ah! Y en este modelo, no vale eso de esperar a que este algo. Lo que no esta a
punto se queda fuera. O se saca lo que hay, o no se saca.
El sistema base podria salir una vez al año, por navidades (traido desde
Finlandia por Papa Noel o desde Oriente por los Reyes Magos). A continuación
saldrian las series, basadas en BaseStable. Este grupo de series podria salir
cada 6 meses, con periodos de estabilizacion cortos.
Por que periodos de estabilizacion cortos?
Un ejemplo: SpamAssassin. En woody tenemos la 2.20-woody.3. Quien usa esa
antigualla? Nadie. Porque es demasiado vieja. Puede que tenga 100+ problemas
de seguridad pero...
1. No hay nadie usando ese codigo. No hay nadie auditandolo.
2. No sirve para nada: sin bayes, con reglas antiguas,...
3. Si se encontrara un problema se seguridad, o un RC, no hay quien haga un
backport a 2.20 de lo cambiado que esta el codigo en 2.61.
Aplicaciones que ofrecen un servicio en el sistema (apache, ssh, bind,...
incluso hddtemp) podrian tener periodos de estabilizacion mas largos (puesto
que no hay una nueva version cada pocos meses y los cambios que incorporan
suelen ser menores) frente a periodos mas cortos de aplicaciones de escritorio
(kde cada 6 meses o gnome cada 4 tienen un porron de aplicaciones nuevas y las
que se mantienen tienen cambios muy importantes).
Resulta absurdo sacar sarge con kde 3.1 o xfree 4.2.1 cuando hasta mi
secretaria con su nuevo y flamante portatil quiere/necesita/va a acabar
instalandose backports de kde 3.4 (que casi que estara para cuando salga
sarge), xfree 4.4 y compañia. Y los backports, no siendo parte de Debian, no
tienen el mimo y el cariño (y las actualizaciones de seguridad) que les damos
los DD.
Un saludo.
--
Jesus Climent info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.4.23|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69
If you think that there is a solution, you'll die here.
--Gibarian (Solaris)
