Premio PFC con Sw Libre

No proceso de integración das aportacións é habitual atopar unha serie de medidas informais para garantir a calidade das aportacións e a súa fácil integración. Mais alén destas medidas, a maioría dos proxectos de software libre prevén etapas de testeo e calidade específicas e coordinan os seus esforzos a través dunha axenda común: os ciclos de release.

Funcionalidades VS tempo

Un ciclo de release consiste no tempo e accións que ocorren entre que se publica unha versión do software ata a seguinte. A grandes rasgos, podemos identificar 2 grandes modos de xestionar o ciclo de publicación dun proxecto:

1. Publicación basada en funcionalidades.
2. Publicación basada en tempo.

Decidir cal dos modelos se adecúa ás necesidades do proxecto, pode impactar directamente na calidade do mesmo. Para elexir o modelo adecuado, é preciso ter en conta certos condicionantes:

• ¿Cómo se decide qué funcionalidades son aceptadas?

Nunha release basada en tempos este proceso é trivial xa que só entran as que están dispoñibles cando se publica a release. Polo contrario, nunha release basada en funcionalidades o proceso implica negociación entre os múltiples colaboradores do proxecto. Este proceso de negociación pode ser lento e dar lugar a continuas discusións que retrasen unha e outra vez a publicación.

O perfil do coordinador da release nun e noutro caso son moi diferentes. Mentres no primeiro caso, o seu papel limítase a xestionar os tempos e contactar cos colaboradores de cada módulo para facer o seguemento do proceso; no segundo ten un perfil máis político, xa que nun momento determinado pode chegar a forzar a publicación da nova versión.

• Control de calidade

A pesar das medidas informais das que falabamos en post anteriores, unha fase de testeo é necesaria para estabilizar o programa.

Nunha release basada en tempos ésta defínese na propia planificación e si todo vai ben debe cumplirse. Nunha basada en funcionalidades, as releases poden ocorrer súbita e forzadamente (logo dun proceso de negociación que se alonga no tempo e os xestores deciden levar adiante a publicación) polo que a fase de control de calidade pode ser insuficiente.

• ¿O proxecto depende de outros?

Si é así, é importante contar coas releases das dependencias. Por exemplo, si o proxecto usa o kernel de linux como base para facer outra cousa, quizás o máis interesante sexa amoldar o ciclo de release do proxecto ó do kernel, xa que dese modo poderase dispoñer en cada versión das últimas melloras que provee o kernel.

• ¿Qué outras axendas dependen do teu proxecto?

O caso do escritorio GNOME é digno de estudio. Logo da release da versión 2.0, decidiron facer as releases cada 6 meses. Este aspecto organizativo, xunto con outras diferencias co seu competidor directo KDE, facilitaron que moitas distribucións de linux o elexisen como escritorio por defecto. Debido a que coñecen cando se publicará a seguinte versión, outros proxectos poden planificar as súas accións (release da distribución, accións de márketing, organización de eventos etc) con antelación.

A este respecto, Mark Shuttleworth, fundador de Ubuntu, publicou recentemente un post sobre a sincronización da pila completa de aplicacións libres no que falaba sobre a estratexia de release de Ubuntu:

[…] at Ubuntu we have converged around the idea of releasing about one month *after* our biggest predictable upstream, which happens to be GNOME. And similarly, the fact that the kernel has their own relatively predictable cycle is very useful. We don’t release Ubuntu on the same day as a kernel release that we will ship, of course, but we are able to plan and communicate meaningfully with the folks at kernel.org as to which version makes sense for us to collaborate around.

• ¿De qué recursos se dispoñen?

A pesar de que as releases basada en tempos teñen grandes vantaxes, necesitan á súa vez unha inxección de recursos importantes, que, si non se dispoñen, poden facer desaconsellable o uso desta ciclo de publicación. Por exemplo, si o proxecto ten unha carencia de programadores que fará imposible sacar regularmente novas versións.

CONCLUSIÓNS

Ó longo deste post, temos visto cómo a sincronización do proxecto ten importancia tanto a nivel interno -garantir a motivación dos colaboradores e unha efectiva coordinación dos esforzos- como a nivel externo -facilitar sinerxias entre proxectos.

Así, elexir o modelo adecuado en cada etapa do proxecto non só afectará ás relacións con outros proxectos e á calidade, senón tamén á motivación dos colaboradores, o codiciado grial de calquera comunidade de software libre.