Document Actions

Qué debo hacer para corregir un bug

by Joaquin Jose del Cerro Murciano — last modified 2012-04-26 15:11

◄ Previous Enlazar los commits y los tickets

Describe cómo saber si un desarrollador puede asumir la corrección de un bug y cómo notificar que ha realizado la corrección

Version:	1.0

Alcance

Este documento describe cómo saber si un desarrollador puede asumir la corrección de un bug y cómo notificar que ha realizado la corrección.

Vamos a distinguir dos tipos de proyectos a efectos de este documento. Por un lado, estarán los proyectos que mantienen un desarrollo activo, se encuentran en evolución existiendo un equipo de desarrolladores trabajando en ellos y añadiendo nuevas funcionalidades o realizando tareas de mantenimiento sobre él. En estos proyectos es claramente identificable quién es el responsable o responsables. Identificaremos a estos proyectos como proyectos activos.

Por otro lado, hay proyectos sobre los que actualmente no no se está realizando ninguna tarea de desarrollo directa. Ningún grupo de desarrollo está trabajando en ellos de forma activa. Suelen ser proyectos que se desarrollaron en el contexto de algún contrato anterior y que tras la finalización de este se disolvió el grupo de trabajo que estaba trabajando sobre él. En estos proyectos apenas hay actividad y en general no está claro quién es el responsable o responsables del proyecto. A estos proyectos los identificaremos como proyectos inactivos. Hay que señalar que un proyecto inactivo no tiene un grupo de desarrollo asociado a él. Es decir, los desarrolladores que trabajaron en el proyecto, no forman parte de este, una vez el proyecto se queda como inactivo, no tienen ninguna capacidad de toma de decisiones y que tengan permiso de commit sobre el proyecto no les otorga derechos especiales en la toma de decisiones del proyecto.

Fase de estabilización

Otro concepto importante a aclarar es el de fase de estabilización. En el contexto de este documento hablaremos de fase de estabilización a la fase previa a la liberación de una versión de un proyecto activo. Si un proyecto tiene un grupo de desarrollo trabajando de forma activa en él, más tarde o más temprano acabará generando una versión para su distribución. Previo a la generacion de esa versión, se abrirá un periodo en el que el equipo se dedicará a estabilizar el proyecto para su liberación. A este periodo es al que aquí denominaremos fase de estabilización.

Antes de abordar la resolución del ticket

Si se trata de abordar un ticket de un proyecto activo que aun no ha entrado en fase de estabilización y forma parte del grupo de desarrollo del proyecto, no precisará de ningún trámite para abordar el ticket. Simplemente tendrá que ponerse deacuerdo con el responsable y comunicarselo, a la par que se asegura que los campos del ticket quedan coherentes (ver más adelante en este documento). Para cualquier otro caso deberé seguir las normas que se describen a continuación.

Warning

Hacer incapie en que una vez un proyecto a pasado la fase de estabilización y ha sido liberada una version final, deberá seguir las normas que se describen aqui, aunque no se disuelva el equipo de desarrollo y este siga trabajando en el proyecto.

En caso que los responsables de un proyecto, precisen usar otros mecanismos para realizar cambios en el proyecto que los descritos en este documento, podran solicitarlo a los responsables de desarrollo y testing.

A la hora de abordar la resolución de un ticket, tendremos que tener en cuenta varias cosas:

Deberemos tener asignado el ticket.

Para abordar la resolución del ticket deberá estar asignado a nosotros. Nunca debemos abordar la resolución de un ticket que esté asignado a otro desarrollador o que no tenga asignación. Tampoco deberemos autoasignarnos el ticket.

Si queremos abordar la resolución del ticket que no tenemos asignado, deberemos añadir un comentario al ticket pidiendo que nos lo asignen.

Es posible que debido a la carga mensajes asociados a tickets, en un momento dado pueda pasarse por alto el comentario con la solicitud... tambien puede realizarla a traves del formulacio de contacto de la web de gvsig.org .
Si está relacionado de la aplicación gvSIG, deberemos verificar que el campo version del ticket se corresponde con el código que voy a modificar.

No deberíamos abordar un ticket que no se corresponde con la versión de fuentes que voy a tocar. Por ejemplo. Si voy a hacer la modificación sobre el trunk, y en esos momentos del trunk se va a generar la versión 1.10 de gvSIG, no deberé abordar la resolución del ticket si este no tiene puesto en el campo version gvSIG 1.10.

Si pone otra versión deberé añadir un comentario y esperar que verifiquen que puede asumir la corrección del tiquet, cosa que llevará consigo cambiar el número de versión o crear un ticket nuevo para la versión correcta y que nunca deberá hacerlo el desarrollador.
Sólo tickets con el campo prioridad a mayor que 1 se podrán abodar.

El equipo de testing ya habrá revisado el ticket y no desea que sea aboardado para la versión de gvSIG que indica.

En caso de que se cumplan favorablemente estas condiciones:

Tiene el ticket asignado.
La versión del ticket es la que se corresponde a los fuentes sobre los que va a trabajar.
La prioridad es mayor que 1.

Podremos abordar la resolución del ticket.

Resolvieldo el ticket.

Una regla importante a la hora de abordar la resolución del ticket, es que no deberemos mezclar la resolución de varios tickets en un único commit. Cada commit que haga solucionará uno o varios problemas relacionados con un sólo ticket. Podemos tener varios commits que solucionen un ticket, pero nunca deberemos tener un commit que solucione varios tickets.

Además tendremos que añadir en el mensaje del commit a qué ticket se corresponde ese commit. Puede encontrar más documentación sobre esto en Enlazar los commits y los tickets.

Cuando el ticket ya está resuelto.

Una vez resuelto el ticket, no basta con subir los cambios al repositorio de fuentes. Además de ello deberemos volver sobre el ticket y rellenar algunos campos y cambiar otros:

Añadiremos un comentario indicando el número de revisión del repositorio que resuleve el ticket. Ver Enlazar los commits y los tickets.
Actualizaríamos el campo resolution, a fixed (suponiendo que esté resuelto el ticket.
Actualizaríamos el campo SubprojectResolveBuildNumber con el número del último build generado más uno.
Actualizaríamos el campo state a closed.