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

Conceptos previos
-------------------

Proyecto activo e inactivo
.............................

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`_.

.. _`Enlazar los commits y los tickets` : /plone/projects/gvsig-desktop/docs/devel/guia-para-commiters-de-gvsig/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.

.. list-table:: Registro de cambios
   :header-rows: 1

   * - versión
     - Descripción

   * - 
     -