2006/1/19, Marcos Guglielmetti <marcospcmusica@yahoo.com.ar>:
On Thursday 19 January 2006 11:22, Jorge Salgueiro wrote:
> > Pero como Musix ha evolucionado muchísimo y ese número 0.31 no
> > representa su evolución, pensé el siguiente esquema:
> >
> > La próxima versión de testeo sería
0.39 (llevada todo lo posible a
> > debian y agnula/testing), luego la versión con los bugs reparados
> > sobre esa anterior sería la 0.40: una versión más estable.
> >
> > Ok, y así.... la siguiente sería
0.49 (llevada a testing o unstable
> > de nuevo), y la próxima sería 0.50
>
> me parece demasiado rápido. Isto por que la distribuición tiene
> todavia algunos problemas de integración con debian... algunos
> paquetes tienen problemas de estabilidad... deberias apuntar el 1.0
> para cuando salga el debian etch... por esa altura el kernel deberá
> estar más estabilizado, como los debianudos dicen que será para el
> final de este año pues seria para mediados del que viene... :D
Puede ser, eso sería (irónicamente) a fines de 2007... mmmm ..... no sé,
me parece muy lento pero puede ser...
si la verdad que es lento... podrias hacer algo como: preparar un roadbook (es bitacora en castellano no?) Ahora en la bitacora pues puedes definir objetivos, y para cuando los quieres conseguir.
0.3.1
0 - beta musix
3.1 - punto tres punto uno del roadbook
existen varias versión rc antes de liberar la version "oficial". creo que seria necesario esperar un tiempo minimo de testeo de estas versiones...como un mes minimo.
> Seria interesante que cada revisión mayor de musix fuese de acuerdo
> con debian, la 1.0 2.0 etc...
Eso no lo entiendo: Debian está en 3.1 estable, no sé qué número será el
próximo estable, quizá 4.0? 3.2? pero se llamará "Etch".
Lo que puedo hacer es lo que decía: mi intención es ir estabilizando un
poco Musix en cuanto a que los programas estén testeados, para eso
debería basarme más en testing que en unstable.
Si nos quedamos en testing, este pronto se transformará un stable, y
será difícil obtener nuevas versiones de programas porque queda todo
congelado y atado a stable. Entonces no podemos hacer eso (podemos pero
quizá no sea lo mejor)por ahora porque los programas para músicos están
en versiones 0.x generalmente, etc.
Pongo el caso de DeMuDi: ellos ataron demudi a debian/stable hace unos
cuantos meses atrás con su versión 1.2.1, lo cual produjo que el
sistema fuera "estable", pero los usuarios se volvieron locos durante
muchos meses para tratar de actualizar Ardour, Jack y compañía a las
últimas versiones: tuvieron muchos problemas para incorporar tamibién
DSSI.... en definitiva, atarte a stable hace que sea más complicado
luego actualizar las cosas a unstable, en cambio estar en testing lo
hace más sencillo.
el problema es que testing varia en su estabilidad: Maxima estabilidad antes de su unión que stable y minima justo despues...
En última instancia puedo hacer una versión de Musix que en algún
momento se ate completamente a Etch... pero por ahora lo que hago es
seguir los pasos teniendo en cuenta otras cosas que debian no tiene por
qué tener en cuenta: la música y la facilidad de uso y actualización.
Nosotros tenemos JACK 0.100 desde Musix 0.26 (10-9-05), en cambio DeMuDi
lo tiene recién 3 meses después(16-12-05), y jack 0.100 mejoró mucho el
comportamiento de jack, yo no volvería a usar un sistema con un jack
anterior ni loco.
concordo, una de las cosas que me gustan más en musix es su bleeding edge. Pero evidentemente eso pueda traer problemas de estabilidad. Mi opinión seria lanzar versiones muy bien testeadas de unstable y mantener unstable. El problema seria que los usuarios tendria de "suportar" alguna instabilidad cuando instalacen paquetes de repositorio debian unstable. Es curioso que normalmente el unstable es más regular en su instabilidad que testing :D
de cierta forma seria hacer algo semejante a kubuntu - nuestro unstable está testado pero se quieres instalar otros programas .... es a tu riesgo (normalmente no hay grandes problemas)
La posibilidad de tener jack 0.100 antes que demudi lo dio el hecho de
que no ate Musix a Debian/stable: es más complicado para mí, y es más
trabajo, pero por ahora lo haré.... luego cuando no sea necesario estar
a "la última moda", dejaremos anclado el sistema en "stable" en lo
posible, y quizá hagamos alguna versión "unstable"
eso acontecerá daqui a algunos años (la tipica frase que obliga uno a morderse la lengua meses despues :D)
> asi evitarias algunos problemas de
> estabilidad, o puedes hacer como knoppix, siempre unstable y que se
> j*d*...
Y.... por ahora será testing/unstable por un buen tiempo...
> o pues asociar-te más al knoppix, en plan, knoppix 4.0 pues lo
> masterizamos para la musica, etc...
>
> son solo ideas...
Musix es una remasterización de knoppix 3.8.2.... sólo tomaría de nuevo
knoppix si las cosas se arruinan mucho y no hay salida, pero por ahora
vamos bien actualizando el sistema: dentro de un tiempo actualizaremos
el kernel del live cd, no será tan difícil, creo.
gracias por las ideas, y por favor que siga el debate, al menos en otro
momento, pero necesitamos debatir estas cosas!
--
Marcos Guglielmetti (
www.pc-musica.com.ar)
Coordinador del desarrollo de Musix GNU+Linux (www.musix.org.ar)
(www.musix.distrux.net)
___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar
_______________________________________________
Musix GNU+Linux - www.musix.org.ar
Musix-Help mailing list
Musix-Help@lists.ourproject.org
http://lists.ourproject.org/cgi-bin/mailman/listinfo/musix-help