.. warning:: **Este documento esta obsoleto, debe ser actualizado**

.. contents::

Este documento pretende aclarar cómo hay que abordar la fase de
estabilización en la rama estable de gvSIG.

¿Qué es el proceso de estabilización?
----------------------------------------

Cuando se va a abordar la generación de una distribución de gvSIG,
se inicia el proceso de estabilización.

Este proceso está dirigido por un equipo de desarrollo especializado
que se encargan de corregir
los bugs que aparecen o gestionar qué responsables de las
distintas áreas de gvSIG deben dar una solución al problema, primando la 
**estabilización** de la aplicación frente a la adición de nuevas funcionalidades
o implementaciones.


¿Porqué se hace necesario tener un mecanismo especial para esta rama?
----------------------------------------------------------------------

Nos hemos encontrado que a la hora de
intentar publicar una versión de gvSIG se entra en fase de test, se
levantan todos los bugs que se detectan, cada equipo de desarrollo
selecciona de la lista de bugs de su área, aquellos que les parecen bien
por la razón que sea, los arregla y los devuelve a los testers para que
se lo validen. El resultado, se arreglan bugs de poca importancia, se
dejan los bugs más complicados o que apetecen menos, se arregla algo
pero se estropea otra cosa, etc... La consecuencia, el proceso de
testing se eterniza y cuando se decide publicar se saca una versión que
en definitiva no es estable.

Objetivo del proceso de estabilización
---------------------------------------

Se pretende durante este proceso corregir un número determinado de bugs
de forma que el impacto sobre otras áreas de la aplicación sea mínimo,
es decir, es preferible arreglar 5 bugs de forma correcta que 20 de
forma incorrecta y que provocan 10 más. Lo más importante durante esta 
fase es la estabilización.

¿Cómo se aborda el proceso de estabilización de la rama estable?
-----------------------------------------------------------------

Para llevar a cabo el proceso de estabilización se designa:
  - Un responsable desde desarrollo.
  - Un responsable desde testing
  - Un equipo fijo de desarrolladores (reducido)
  - Un equipo fijo de testers
  - **Una fecha orientativa de obtener la revisión**.

Lo primero que se hace cuando se decide iniciar el proceso de
testing/estabilización es formar un grupo de trabajo.
Hace falta una persona designada por la CIT que decida que bugs son
prioritarios y hay que arreglar, estos son en definitiva los bugs que
hay que arreglar y no otros. Esta persona será el responsable de testing.

Por otro lado se designa un responsable en la parte de "desarrollo", su
labor consiste en coordinarse con el responsable de testing y decidir
qué bugs hay que arreglar, asesorando al responsable de testing en las
partes "técnicas".

También se designará a un desarrollador responsable de cada
area/componente/proyecto que será quien asesore al responsable de
desarrollo sobre el coste e impacto de cada ticket y de su realización 
encaso de que se decida abordarlo.

Si se considera oportuno, se pueden añadir al equipo de desarrollo
testers para
que se encarguen de realizar las pruebas oportunas sobre los tickets
abordados
antes de dejar la distribución al responsable de testing para que los
valide.

Es fundamental que exista comunicación diaria entre estos 2 grupos de
trabajo de manera que el "responsable de testing" sepa en qué estado están
los bugs que se están corrigiendo y el "responsable de desarrollo" sepa
el impacto que se está produciendo por el arreglo de los bugs.
Igualmente el "responsable de desarrollo" debe ser informado del estado 
y contratiempos encontrados en la elaboración de las tareas por parte de 
los desarrolladores y testers, para coordinar las posibles correcciones 
en la planificación de la estabilización con el responsable de testing.

Es fundamental que se establezca una fecha orientativa para obtener una 
revisión, es decir, no hay que arreglar todos los bugs que se encuentren,
hay que fijar un número determinado y una fecha en la que se debe tener
una versión.

Durante este periodo los desarrolladores deben dejar a un lado la 
capacidad para detectar bugs y corregirlos de forma inmediata.
Todos los bugs deben darse de alta en la aplicación de seguimiento de
bugs, y los responsables de la estabilización en desarrollo y
testing asignarán prioridades y determinarán si deben o no corregirse
para esa versión.

Los desarrolladores corregiran únicamente los bugs que les sean asignados.
Y si detectan algún otro se limitarán a darlo de alta.

Inicio del proceso de estabilización
--------------------------------------

El proceso se inicia cuando el responsable de testing de gvSIG se pone de acuerdo 
con el responsable de desarrollo de gvSIG. Entre ellos deben designar al responsable 
de testing y el responsable de desarrollo para el testing que se vaya a realizar. Deben
establecer también los recursos que se van a destinar para realizar el testing.

Una vez designados los recursos, se actualiza en la sección `seguimiento de bugs `_, el apartado 
"fase de test" del producto que se va a testear, estableciendo las personas implicadas 
en el proceso.
Se manda un correo a la lista de gvSIG indicando que se inicia la fase de test 
de "lo que se esté testeando", los responsables y los participantes. A partir de este 
correo el seguimiento se hará siguiendo este hilo.

Los 2 responsables designados (testing y desarrollo) establecen el número de bugs que 
se resolverán,siendo el responsable de testing el encargado de decidir cuáles son los 
que deben resolverse. Ambos responsables deben comunicarse diariamente 
la evolución de los bugs y el estado del testing.


Comunicación entre coordinadores.
----------------------------------

Durante toda la fase de test, los resposables de test y desarrollo
deben tener un contacto telefónico diario (normalmente al final 
del día) o delegar en alguien que se encargue de realizar dicha comunicación.

Dependiendo de la planificación y necesidades, debería hacerse
una reunión semanal o bisemanal entre ambos y los tecnicos/testers que se
considere oportunos.

Comunicación del equipo de desarrollo.
----------------------------------------

Diariamente, en la medida que las localizaciones los permitan, el
responsable de desarrollo se reunirá con los desarrolladores y testers 
para ponerse al corriente (y también comunicar) del estado del proceso. 
Esta reunión debería realizarse aunque su duración sólo sea de unos minutos.

Si la localización de alguien del grupo no le permite estar en la reunión
diaria, el responsable de desarrollo solicitará diariamente (si es 
necesario) información del estado de las tareas a dicha persona.
El responsable de desarrollo se pondrá en contacto con el desarrollador o 
tester que necesite en cualquier momento para consultarle sobre el
estado de un ticket y viceversa.

Es importante que, ante cualquier duda, cambio, contratiempo o
problema, el responsable de desarrollo sea informado lo más rápidamente 
posible para poder actuar en consecuencia también con agilidad.

Asignación de tareas
----------------------

Una vez el responsable de testing y de desarrollo quedan de acuerdo en 
los tickets a abordar, el responsable de desarrollo comunica y asigna 
las tareas a los desarrolladores responsables de área y el orden en el 
que se abordan siempre asesorado por los mismos desarrolladores.

Gestión de los tickets
-----------------------

Cómo comunicar un bug. 
=======================================

Como regla general toda actuación en el código tiene aparejado un 
ticket, esto sirve para todos los proyectos, pero en la estabilización 
de una versión cobra una importancia vital. No se arregla nada si no 
existe un ticket asociado.

Cuando se detecta un bug se debe dar un ticket de alta al igual que 
cuando se da de alta una tarea, rellenando los campos,

- Summary, Descripción corta del bug

- Type, debe seleccionarse "bug".

- Descripción, en este campo debe describirse lo más detalladamente
  posible los pasos que se han seguido para detectar el bug.

- Prioridad, este campo **debe** ser fijado por el responsable de
  testing, la persona que lo detecta puede establecerlo de forma
  orientativa, pero es el responsable de testing el que debe establecer
  la prioridad definitiva.

- CC, personas que deben recibir una copia de las notificaciones de
  este ticket.

- Versión, en qué versión de gvSIG se detecta el bug por primera vez.

  **Una vez que se establece no puede cambiarse.**

- Build number, indica en qué build se ha detectado el bug. **Una vez que
  se ha establecido no debe cambiarse**.

- Componente, de la lista de componentes asociados a gvSIG cuál es el
  que produce el error. Este campo debe rellenarse si se conoce el
  componente. que produce el error.

- Proyecto, dónde se ha detectado el bug, en qué proyecto se ha
  detectado.

- Archivos adjuntos. Es muy recomendable adjuntar el log de gvSIG.
  También pueden adjuntarse capturas de pantalla, fuentes de datos y
  aquella otra información que se piense clarifica el problema o aporta
  datos que puedan ser de utilidad.

A partir de ese momento, el ticket se queda a la espera de que el
responsable de testing tome la decisión de si se aborda en la siguiente 
revisión o no, además de su prioridad. Es por tanto el responsable de 
testing el que debe establecer el campo

- Resolve version, indica en qué versión de gvSIG se debe resolver el bug.

Para más información ver `Cómo comunicar un bug `_


Evolución/seguimiento/modificación de un ticket
==================================================

Una vez que un ticket se ha dado de alta, el seguimiento y evolución se
realiza a través de los comentarios del ticket, es decir, si por ejemplo
la persona encargada de resolverlo necesita que la persona que ha dado
de alta el ticket aporte algún dato más abrirá un comentario solicitando
lo que necesite. Si la información que necesita no se le tiene que
proporcionar la persona que dio de alta el ticket puede añadir a la
persona que debe proporcionarsela en el CC del comentario.

Hay que tener en cuenta que los campos VERSIÓN y BUILD NUMBER **no**
deben cambiarse.

Cierre de un ticket
====================

Una vez que el arreglo se ha realizado, la persona encargada de
realizarlo añade un comentario que tendrá como mínimo el changeset y
cambia el estado del ticket a cerrado seleccionando la opción resolve
as: "fixed".

Sería recomendable que en el comentario se hiciese una descripción de
cuál era el problema en el código y lo que se ha hecho para su resolución.

Además establecerá el campo

- Resolve build number, una vez que el bug ha sido resuelto se establece
  la versión (build) en la que estará disponible la corrección.

Validación de un ticket
=======================

Cuando el ticket pasa al estado "fixed" y la resolución esté disponible
para los testers, estos deben comprobar que efectivamente está corregido
el problema. Si es así se cambia el estado a "validated", si no es así y
el problema persiste se reabrirá el ticket con un comentario indicando
que el problema no se ha resuelto y aportando aquella información que se
considere que puede aclarar lo que está pasando.