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 ) 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.