[BulmaGés]Consultas a los developers

[Leopold Palomo Avellaneda]

A Divendres 20 Juliol 2007 21:23, Tomeu Borras va escriure:
> > releases serian los tags de cvs, y seria como una foto de trunk en un
> > momento, con un número, que en nuestro caso seria como decir, ok, trunk
> > está suficientemente maduro, hagamos una etiqueta y hacemos una foto en
> > releases.
> >
> > branches seria como ramas, como pruebas o alternativas. Aquí yo no tengo
> > claro que se haya de poner estable. No es una rama. Yo creo que se
> > desarrolla en trunk, se etiqueta cuando se diga en tags (releases) y se
> > experimenta o hacemos cosas paralelas en branches.
>
> No es del todo correcto este planteamiento. Imaginaté que estamos
> trabajando en el trunk con Qt 4.3 y que la estable esta en Qt4.2. Si
> aparece un bug derivado de las Qt4.2 hay que corregirlo, pero no interesa
> tener a la gente que usa el programa pendiente de que el trunk se haya
> estabilizado para liberarles la nueva versión pq pueden pasar meses.
>
> Tampoco es bueno trabajar sobre los tags pq entonces nunca podremos
> recurrir a la versión que se liberó. Lo suyo es arreglar los problemas en
> la rama estable y liberar de nuevo sin que sea la parte del trunk.

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.

También se puede cambiar la norma y liberar por ejemplo:

tags (releases)
0.9
i aquí dentro
0.9.1
0.9.2 
....
donde el último número es el patch level, o número de corrección. Por lo 
tanto, si la 0.9 és la estable, los 0.9.x serán los niveles de corrección.


> > Por tanto yo sacaría la rama estable. Para mi no es una rama. Y mira que
> > yo creo que hice el directorio branches/release-0.5.3, pero no va ahí.
> >
> > > > Viendo los commits que hiciste hace unos días, me recuerdo que hay
> > > > una cosa que me toca un poco las narices en la estructura del código:
> > > > la existencia de directorios .moc, .obj, .ui en el repositorio.
> > > > Además creo que no hay ninguna regla para crearlos, cuando son
> > > > directorios totalmente temporales de salida de programas. Que os
> > > > parecería modificar el .pro para que los cree si no existen i
> > > > sacarlos del svn?
> > >
> > > Basta con sacarlos el svn ya que el .pro por defecto los crea si no
> > > existen. A mi también me disgusta verlos.
> >
> > 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.

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

> > > Estoy planteando si no será mejor que los .pro generen los ts
> > > directamente dentro del installbulmages (mala idea) o en un directorio
> > > específico para traducciones para luego tener las traducciones
> > > agrupadas y controladas.
> >
> > si los plugins siempre van ligados al programa, quiero decir que no es
> > posible plantear un paquete aparte, ponlos donde quieras, ya que luego el
> > empaquetador los instala donde crea oportuno.
>
> 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 ... :-)

> > > > 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?

> Supongo que lo dices por el empaquetado Debian que tiene que hacer cosas.
> Yo ahi no me he meto, sólo se que no podemos dejar de emitir el instalador
> genérico ni podemos adaptar éste para que sólo funcione en Debian.

estamos de acuerdo.

Leo

-- 
--
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/638eea50/attachment.pgp