[BulmaGés]Fwd: Re: Consultas a los developers

[Tomeu Borras]

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

> 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




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


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


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

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.

Salut

-- 
Tomeu Borrás Riera
Conetxia Soluciones informáticas
971 29 06 29
http://www.conetxia.com