Cómo xestiona GNOME as releases

Posted by admin on August 28, 2008

O ciclo de lanzamento dun proxecto comprende tarefas dependentes unha das outras: mentres o desenvolvedor non remata de facer as modificacións ó programa e engadir/modificar/eliminar as cadeas que se presentarán ó usuario (en forma de diálogos, por exemplo), os tradutores non deberían comezar a facer o seu traballo. Estas interdependencias son habitualmente xestionadas mediante os períodos de conxelación (freezes) ós que se lle asignan datas e a partir dos cales non se poden facer certos cambios.

O ciclo de release do proxecto GNOME está baseado en períodos de publicación de 6 meses, onde se estipulan certos puntos de sincronización de traballo. Algúns dos freezes existentes son:

freeze schedule

Un maior detalle de cada un deles pódese observar dentro da propia páxina de GNOME.

Así, para cada versión do proxecto publícase unha axenda onde se indican os períodos de freeze. Deste modo, os colaboradores poden organizar o seu traballo de acordo a un timeline común. Existe tamén un equipo encargado da xestión da release que vela -entre outras cousas- porque a axenda se cumpla así como da aceptación/denegación dos freeze breaks: a pesar de que existen uns períodos de conxelación para sincronizar o traballo, éstos non son ríxidos e sempre queda a opción de pedir permiso para realizar cambios.

Como exemplo de xestión, podemos ver esta petición de break freeze, onde se plantexa a modificación dunha cadea de traducción (mais o período para modificar as cadeas de traducións xa pasou). A petición é enviada á lista do equipo xestor da release (seguindo as normas do proxecto) para que decida qué facer con ela (valorando si pode ou non retrasar significativamente a release). Seguindo o fío da conversa na lista de correo, podemos ver cómo neste caso a petición é aceptada e a cadea cambiada satisfactoriamente.

Na propia páxina do proxecto podemos observar unha panorámica do lanzamento de Gnome 2.23:

gnome schedule

O escritorio GNOME comprende múltiples módulos e colaboradores traballando en paralelo, polo que medidas como as que acabamos de relatar son necesarias para publicar cada 6 meses unha release de calidade. Porén, é habitual que os puntos de sincronización sexan máis informais cando un proxecto é menor en tamaño, ten menor número de colaboradores ou o modo de organización é diferente.

Trackbacks

Trackbacks are closed.

Comments

Comments are closed.