Cómo abordar la resolución de un bug/Feature/Task (desarrolladores)
========================================================================

Antes de empezar
-------------------

Cuando un desarrollador va a abordar la resolución de un bug, 
lo primero que debe hacer es  **asignárselo** (si no lo tuviese asignado ya) 
y luego **aceptarlo**. De esta manera se informa al resto de
desarrolladores que *ya se está investigando sobre el tema*.

Recordar que, *sobre la rama estable o en periodo de estabilización*
**No se debería abordar** la resolución de un Ticket **sin 
conocimiento/consentimiento** del **responsable o del coordinador de testing**.

El bug pasará a estado *asignado* (`estados de un ticket 
<../faq/estados-de-un-ticket/>`_ ) y
el desarrollador se puede poner a resolver el problema.

Comunicación
------------------

Si durante este proceso necesita comunicarse con el 
tester o con alguien más, añadirá en el campo *CC* a los 
usuarios/direcciones de quiénes necesiten ser informados y hará
el comentario en el propio ticket.

Las comunicaciones entre tester y desarrollador deberían ser a través
de los comentarios del Ticket para así tener todo el seguimiento de 
la tarea. Si hubiese comunicación por otros medios, sería necesario
reflejarlo en la tarea, aunque sólo fuese un resumen.

Dentro de los comentarios de los tickets se puede hacer referencia
a otro ticket con el siguiente formato:

::

   {abr_trac}:#{numero_ticket}

Donde:

+ **abr_trac** : *Opcional*, se requiere sólo si el ticket es de otro trac. Abreviatura del Trac donde está dado de alta el ticket. Normalmente **bug** para *Bugtracking* y **core** para *gvSIG Core*. Para otros Tracs consultar.

+ **numero_ticket** : Número del ticket al que hace referencia.




Subir cambios
-------------------

Cuando el desarrollador requiera cambios, para realizar la tarea,
en algún proyecto en el que no tenga permisos, deberá adjuntar 
un *patch* al ticket y reasignarlo a algún desarrollador que 
tenga permisos para ello.

Cuando se suba algún cambio al repositorio, en el **comentario del commit**
deberá incluirse una referencia a la tarea que lo ha generado. Esto
se hace con el siguiente formato:

::
  
  {comentarios del cambio}

  {abr_trac}:#{numero_ticket}


Donde:

+ **abr_trac** : Abreviatura del Trac donde está dado de alta el ticket.Normalmente **bug** para *Bugtracking* y **core** para *gvSIG Core*. Para otros Tracs consultar.

+ **numero_ticket** : Numero del ticket al que hace referencia.


De esta forma, los cambios quedarán *enlazados* al ticket. Al subir
estos cambios, el SVN genera unos *número de cambios* o *changeset*
que identifican las modificaciones subidas al repositorio. Estos,
para mantener el *enlace*, deberían **anotarse en los comentarios
del ticket** con el siguiente formato:

::
  
  {Comentarios}

  SVN {Rama} [gvsig {numero_changeset}] [gvsig {numero_changeset2}] ...

Donde:

+ **Rama** : Rama del SVN donde se hicieron los cambios. Normalmente **trunk** o **branches/v10**.

+ **numero_changeset** : Número identificador del cambio en el repositorio. Este número se muestra en la *consola de SVN* cuando se hace el *commit* o se puede averiguar con el *Team/Show resoerce history* de los ficheros modificados.


* *Nota*: Para facilitar el seguimiento es *aconsejable* intentar
  *agrupar los commits* en la medida de lo posible.


Cerrar la tarea
-------------------------

En caso de que el bug quede arreglado, lo dejará resuelto como *fixed*, 
y rellenará los campos *resolve versión* y
*resolve build number*. Esto datos se pueden averiguar mirando
la pagina *fase de test* de la versión (el siguiente al último generado)
o en caso de duda, al responsable de empaquetado o al responsable
de distribución.

En **ningún caso** deberá cambiar el valor de los campos *versión* o 
*build number*. 

Si el bug no puede ser arreglado dejará su resolución como *wontfix* y
dejará en blanco los campos *resolve XXX*.

Si el bug está duplicado se pondrá en el campo *resolución* el valor *duplicate* y en sus 
comentarios se incluirá una referencia al ticket dónde quedó resuelto. Para referenciar al otro ticket
ver el apartado `Comunicación`_ de esta página.

Cada vez que se corrige un bug, o se realiza alguna tarea relevante que
vaya a ser incluida en un bug de gvSIG, el desarrollador, además de 
actualizar el ticket correspondiente, deberá añadir a la pagina 
de *fase de test* del producto que se haya visto afectado 
el enlace al ticket en la versión/build que corresponda, el título del
enlace será el mismo que el del ticket,
o la nota que refleje la tarea que ha realizado. De esta forma los
testers podrán realizar la validación adecuada a los
trabajos realizados.
Esta acción hay que realizarla por cada uno de los tickets/bugs que se hayan corregido.