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...
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. 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. 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"
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