Premio PFC con Sw Libre

Si a modularidade do proxecto é un factores clave para aumentar a participación, o proceso de integración das aportacións é primordial para que non morrer de éxito, é dicir, que a xente continúe participando á vez que se obtén un producto de calidade. Así, as preguntas que debemos responder son as 2 seguintes:

• ¿cómo combinamos cada unha das aportacións nun todo, nun producto final?
• ¿cómo aseguramos a calidade das aportacións?

O modo en que habitualmente as resolven algúns proxectos de software libre supón unha conxunción de uso de ferramentas e cumplimento de certas normas sociais que agora pasamos a relatar.

Ferramentas

A continuacion enumeramos algunhas ferramentas que facilitan o traballo distribuido entre múltiples colaboradores (programadores, traductores, …) xeográficamente dispersos. Aínda que non publicaremos tutoriais de cada unha delas, sí faremos en próximos post unha breve introdución ás máis relevantes.

De cara a entender a súa función, podemos agrupalas nas seguintes categorías:

• Sistemas de control de versións: úsanse para o mantemento, integración e distribución do código fonte dos programas. Exemplos: svn, cvs, git, bazaar.

• Xestión da compilación e configuración. Na compilación e release do producto final é habitual ter que facer unha serie de tarefas repetitivas. Para realizar este tipo de tarefas existen algunhas ferramentas que nos axudan a automatizalas. Exemplos: autotools (autoconf, automake, libtool), ant.

• Sistemas de xestión de incidencias: usadas para a publicación e xestión de bugs encontrados no programa. Nalgúns casos úsanse para listar funcionalidades interesantes para o proxecto. Exemplos: bugzilla, trac.

• Sistemas de monitorización do desenvolvemento (nightly build tools): este tipo de ferramentas son usadas para compilar automáticamente o código e xerar informes (erros de compilación, detección de regresións, …). Exemplos: tinderbox, maven.

As dúas primeiras categorías encaixan á perfección dentro do proceso de integración das aportacións nun producto final: as facilidades que nos dan ferramentas tipo svn ou autotools son inmensas e reducen o coste da integración.

Pola contra, nas últimas 2 categorías encaixan ferramentas especialmente deseñadas para realizar o control de calidade das aportacións.

Procesos e boas prácticas

A continuación agruparemos unha serie de prácticas que se realizan habitualmente nas comunidades e proxectos de software libre que podemos encaixar dentro dos procesos de integración e control de calidade. Evidentemente, existen moitas máis e cada proxecto ten as súas propias. Sirvan éstas simplemente como mostra.

Prácticas relacionados co control da calidade e revisión de código entre pares (peer review):

• Lista de correo de cambios (commits): é común que exista unha lista de correo á que se envían de modo automático os cambios no repositorio do proxecto. Deste xeito, todo o mundo suscrito a esa lista pode observar os cambios que foron feitos, detectando erros e aportando melloras.

• Revisión de parches: ter unha persoa que revise o código que o resto do grupo lle envía. Sólo esta persoa pode enviar os cambios ó repositorio de código do proxecto.

• Grupos de calidade: en certos proxectos existen grupos específicos dedicados á calidade. No proxecto GNOME, por exemplo existe a Bugsquad que se dedica a explorar o xestor de incidencias e bugs, tratando de cerrar aqueles que xa estén resoltos ou repetidos. Con esta práctica están axudando ós desenvolvedores dos proxectos que poden centrarse nos erros realmente importantes. Incluso se chegan a realizar eventos coa única finalidade de realizar esta tarefa.

Prácticas relacionadas coa integración das aportacións nun todo:

• Política de cambios: unha serie de normas que definen cómo se deben facer os cambios no repositorio de código. É normal, por exemplo, atopar a regla de nunca subir cambios que provoquen que o proxecto non compile. Este tipo de normas sociais facilitan que programadores que desexen subir os seus cambios, non se vexan obligados a resolver erros cometidos por cambios introducidos anteriormente.

• Coding style. É habitual que cada proxecto teña o seu estilo de programación, que facilite a lectura e revisión do código. Moitas veces os parches son denegados porque o código enviado non sigue as reglas de estilo do proxecto. Ex: Gnome Coding Style, Mozilla Coding Style Guide.

Por outra banda, existen convencións para o uso de cada ferramenta que se deben explorar a medida que se usan.

Ademáis destas medidas informais integradas no traballo diario, no propio fluxo de publicación do proxecto poden existir fases específicas dedicadas a testear o funcionamento do programa ou á integración. Así, marcarse un plan e ter unha axenda clara que sirva como sincronización dos esforzos, é unha das accións principais que poden favorecer a evolución do proxecto.

Para finalizar, máis que tomar nota de cada unha das prácticas e ferramentas descritas, para liderar un proxecto de software libre, é necesario comprender que a integración das aportacións e os mecanismos de control de calidade son necesarios para que o proxecto non morra de éxito.