On Thu, Jul 13, 2000 at 09:05:29AM +0200, Antonio Castro wrote: > : Paul J Thompson thinks that Debian is reaching "critical mass" of > : public recognition. He cites the increasing number of > : [11]distributions based on Debian, the many people and projects that > : are beginning to release debian packages and support Debian, etc. With > : growth comes problems, and Paul identifies two key problems that are > : nothing new: the unmanageable number of packages, and release schedule > : difficulties. He goes on make a "radical" suggestion to address the > : problems -- split up Debian into several sections like core, rapid > : development, and so on, that have different release schedules. It's an > : [12]interesting message, well worth reading even if you [13]disagree > : with his ideas.
Para m�, este modelo de "grupos de paquetes" es inmanejable. El modelo de
Anthony Towns es autom�tico y por lo tanto, es m�s f�cil que funcione.
> Me gustar�a leer eso pero acabo de decir que no siempre entiendo lo que
> se dice en Ingles y por eso pregunto las cosas en esta lista. Si puedes
> mencionar aunque sea la idea general te lo agradecer� aunque yo pienso
> que todas las soluciones t�cnicas que han ido surgiendo para combatir
> los problemas derivados del aumento en n�mero de paquetes se quedan cortas
> o surgen problemas por otro lado. El aumento en el tiempo para estabilizar
> una versi�n ser�a en mi opini�n quizas el problema m�s importante en este
> momento.
Por un lado est� la distribuci�n `testing', que sustituye a `frozen'. El
modelo ser�a ago as�:
[ Stable ] -- Updates m�nimos, seguridad, bugs vergonzosos...
/--> [ Testing ] -- Distribuci�n actualizada moderadamente, com paquetes
| que han probado su calidad.
|
\-- [ Unstable ] -- Todos los paquetes nuevos van a esta distribuci�n.
Joder, que infograf�a m�s total.
La idea es tener una distribuci�n "casi preparada" para el release
permanentemente, y que no pase lo que ha ocurrido con Potato, que al
congelar hab�a m�s de 300 bugs cr�ticos. Como?
Los paquetes ahora se suben s�lo a unstable. Ah�, la gente que usa esa
distribuci�n los testea. Si nadie les pone un rcbug durante 14 d�as, pueden
pasar a ser "aptos" para `testing'. Un script mira los paquetes de unstable,
y ve que "foo" tiene 14 d�as de vida y ning�n rcbug. Mira las dependencias,
ve que no hay ning�n problema, y autom�ticamente coge el paquete y lo
instala en testing.
Esto es la idea b�sica, y se supone que testing s�lo deber�a tener unos 10
bugs cr�ticos permanentemente. Me parecen pocos, pero vamos, no ser�n 300 :)
Tiene problemas, si alg�n paquete saca versiones or revisiones cada menos de
14 d�as, nunca llegar� a testing, o el posible caso de que todo el mundo que
usa unstable ahora se pase a testing ya que es mucho m�s seguro (aunque
siempre quedar� la gente que no puede esperar 2 semanas), y otros temas
similares.
> Bueno pues yo creo que Debian con la estructura actual no escala bien.
> Es una estructura en forma de rastrillo. Hay demasiada gente trabajando
> al mismo nivel. Es decir trabajando en el mantenimiento de paquetes.
> Las tareas de tipo global se ven sobrecargadas de trabajo. Por esa raz�n
> falta gente y sobra gente. Es un problema de organizaci�n.
Y que quieres? Una estructura piramidal? Yo no, desde luego.
> Creo que el mensaje anterior de Debian.news de dividir en secciones la
> distribuci�n servir�a precisamente para organizar secciones con cierto
> grado de independencia. Me sorprende que no se hiciera antes.
Por lo EMHO, inmanejable que ser�a coordinar todos los grupos.
--
Jordi Mallach P�rez || [EMAIL PROTECTED] || Rediscovering Freedom,
aka Oskuro in || [EMAIL PROTECTED] || Using Debian GNU/Linux
Reinos de Leyenda || [EMAIL PROTECTED] || http://debian.org
http://sindominio.net GnuPG public information: pub 1024D/917A225E
telnet pusa.uv.es 23 73ED 4244 FD43 5886 20AC 2644 2584 94BA 917A 225E
pgprAHsJhYyZT.pgp
Description: PGP signature
