[BulmaGés] Consultas a los developers

[Leopold Palomo Avellaneda]

A Divendres 20 Juliol 2007 22:16, Tomeu Borras va escriure:
> > Tomeu estás pensando en cvs no en svn!!!!
> >
> > No es cierto lo que dices. Tu trabajas en trunk y cuando el aquello está
> > lo suficiente maduro para decir, de acuerdo liberamos esto es cuando se
> > hace una copia (virtual, no real) del trunk a releases (tags) en nuestro
> > caso. Y seguimos trabajando.
> >
> > Si en algún momento pasa que : ostres un bug en la X.X.X, que para
> > nosotros es estable, lo que sea, se corrige allí, en la tag, que seria la
> > release. De esta manera, aquel directorio siempre tendrá algo estable y
> > funcional
>
> Y cuando alguien diga tengo un problema en la versión 0.9.3  Como sabremos
> si es antes de haber hecho tal modificación o después de haber modificado 
> y en cual de las modificaciones ?
>

creo que está mal planteado y no estoy de acuerdo contigo en el modus 
operandi. Si en la idea, pero no como se hace.

> Para mi una liberación es una imagen estática (e inamovible) sobre la que
> no debes cambiar nada. No puedes tener una 0.9.3 con un bug y una 0.9.3 con
> el bug arreglado.

Estoy de acuerdo.

Mira, propongo una cosa. Es un tema de numeración y ya está.

Si quieres seguir con tres números : x.x.x

libera la x.x.x con un tag, y cada vez que se encuentra un bug se arregla y se 
libera una modificación le pones una letra. Por ejemplo:
0.9.3
i aquí dentro la
0.9.3-a
0.9.3-b
0.9.3-c
etc

és la versión 0.9.3 con las revisiones de bugs a,b,c


si prefieres no tener tanta numeración, des de la x.x.x

por ejemplo, libera la 0.9.0 donde el último número és el patch level (como 
kde) la base és la misma i solo se arreglan coses y se incorporan muy pocas 
cosas.

Tomeu creo que es un lío todo el tema de las versiones y te lo digo de buen 
rollo. Yo no estoy de acuerdo como se lleva. A la hora de empaquetar es 
un "rollo patatero" y a la hora de colgar en la web versiones también. 
Aprovechemos las funcionalidades del subversion. 

Tengo la sensación que ya me he "discutido" contigo con el tema de la 
numeración ....


> > > > pues si os parece bien, hago de mrproper y empiezo a eliminar. Por
> > > > cierto Tomeu, tu que conoces bien los .pro, que tal añadir un rm -rf
> > > > o delete de los .obj, .ui y .moc? se puede hacer?
> > >
> > > Por ejemplo
> > > $find . -name ".obj" | xargs svn del
> >
> > Tomeu, eso no es lo que te digo. Te estoy diciendo que a nivel de
> > Makefile por ejemplo seria:
> >
> > clean:
> > 	rm -rf .obj; rm -rf .moc; rm -rf .ui; rm -rf .o
> >
> > pero eso dentro de un .pro y portable a todas las plataformas. No puedes
> > ejecutarlo en un windows creo.
>
> Hombre, a mi me molesta que esten subidos al svn (y sólo relativamente)
> pero tampoco me han supuesto un problema como para buscarle una solución
> aparte de quitarlos del subversion.

ok pues los quito del svn. Peró yo me refería a la hora de hacer un make 
distclean.

> > > > > > También, hay otra cosa que no encuentro muy oportuna. Las
> > > > > > traducciones van a un directorio /traducciones que os parecería
> > > > > > cambiar el nombre por i18n?
> > > > >
> > > > > Ese no es el peor de los problemas, el problema real es que cada
> > > > > plugin va acompañado se sus respectivas traducciones y el control
> > > > > de todos estos archivos va a ser duro.
> > > >
> > > > por qué? es parte del código fuente. No entiendo el problema, por
> > > > favor puedes explicarte?
> > >
> > > Fácil, que va a haber muchos, muchos muchos archivos de traducción,
> > > plugins x idiomas y eso es mucho archivo.
> >
> > no es un problema de número, si no de orden y donde los metas. La
> > cuestión para mi es tener cada código donde toca con cierto criterio. Me
> > da igual el criterio, pero que sea claro. Si los plugins van en un sitio
> > ok todos juntos de acuerdo, si cada programa tiene sus plugins asociados,
> > de acuerdo. Pero que esté claro.
>
> i18n está muy bien. Pero ten en cuenta que luego habrá que organizar las
> traducciones de alguna forma adicional por un tema de volumen y de
> combinación de plugins, no tengo claro cual es la mejor forma de hacerlo y
> tampoco me he puesto a pensarlo mucho pero intuyo que habrá problemas en
> esto y requerirá de una estructuración de directorios.

yo creo que las traducciones vayan en un directorio aparte y siempre se podrá 
hacer un paquete bulmages-i18n

> Pero hay otras posibilidades tb que son interesantes, como meter
> traducciones de programa y plugins en un mismo archivo ts.

no lo entiendo.

> > > Pero es que si es posible plantear un paquete aparte. Tiene muchas
> > > posibilidades la cosa.
> >
> > De acuerdo, hoy he preguntado en un correo que me dijerais que plugins
> > corresponden a cada programa y aún espero ... :-)
>
> En el trunk se ha hecho hace dos dias una reorganizacion (Además muy bien
> hecha y muy simetrica con respecto a todo). Dentro de cada directorio de
> programa hay una carpeta src y otra plugins. La src contiene el codigo
> fuente del programa y la de plugins los plugins que se le pueden acoplar.
> Hay plugins en bulmacont, en bulmafact y en bulmalib (los de bulmalib no es
> que sean de bulmalib, es que son validos en todos los programas). En el
> lanzador también habrá plugins pero de momento no hay ninguno hecho.
>
ok, los miraré uno a uno ....

> > > > > > Otra cosa, que pasos se han de seguir cuando se instalar bulmages
> > > > > > sobre una instalación ya hecha? Qué se hace con las bases de
> > > > > > datos?
> > > > >
> > > > > El script installbulmages-server se repasa las bases de datos
> > > > > creadas y les aplica los oportunos parches que hacen falta para esa
> > > > > base de datos (También hace backups por si las moscas, etc). Asi
> > > > > que por esta parte esta solventado. Sólo requiere que los
> > > > > desarrolladores sean concienzudos con los archivos sql de
> > > > > actualización.
> > > >
> > > > Ya, pero como? quiero decir, se ha de hacer un proceso manual en el
> > > > que el instalador llame a ese script? o lo ha de hacer el usuario
> > > > cuando actualiza? Por cierto, el lanzador lo he puesto en el 0.9.3.
> > >
> > > No confundamos. Lo que nosotros liberamos es el installbulmages,
> > > independiente de toda distribución y con un instalador genérico que se
> > > debe ejecutar como root.
> >
> > De acuerdo.  installbulmages-server y el
> >  installbulmages-client
> >
> > y el bulmacont?
>
> Van todos en el mismo script. Se actualiza tanto bulmafact como bulmacont.

ok, pero si alguien quiere solo instalar bulmacont y no bulmafact que hace? 

Leo

PS Tomeu, siento si soy un poco duro, pero a veces me desespero un poco cuando 
intento hacer algo con bulmages y no puedo ....

-- 
--
Linux User 152692
PGP: 0xF944807E
Catalonia
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : no disponible
Tipo       : application/pgp-signature
Tamaño     : 189 bytes
Descripción: no disponible
Url        : http://llistes.bulma.net/pipermail/bulmages/attachments/20070720/e82ac050/attachment-0001.pgp