Re: [Musix-Help] ¿qué piensan que deberíamos hacer con esto?

[Jorge Salgueiro]

2006/1/19, Marcos Guglielmetti <marcospcmusica en 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 en lists.ourproject.org
> http://lists.ourproject.org/cgi-bin/mailman/listinfo/musix-help
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: /pipermail/musix-help/attachments/20060120/b5f83936/attachment.html