Introducción

En estos documentos podra encontrar informacion que es relevante si es un commiter de gvSIG.

Le ayudara a saber cuando puede y como modificar el codigo de gvSIG, como debe hacer para reportar bugs, o como tiene que empaquetar una extension de gvSIG.


Qué debe saber...

Qué debe saber un committer en gvSIG

Que debe saber un empaquetador de extensiones en gvSIG

Note

En construcción.

Aquí habría que añadir enlaces a la documentación relevante para el responsable de empaquetar una extensión de gvSIG con algo de explicación que la hilvane.

Cómo dar de alta bugs

Alcance

Este documento pretende ser una guía rápida que ayude a un desarrollador a dar de alta un bug en el sistema de bugs de gvSIG.

Exclusiones

No se trata de una guía genérica de como dar de alta bugs para un no desarrollador. Para cubrir esto acuda a la documentación:

En relación a esta documentación, el desarrollador también debería estar familiarizado con ella.

Descripción

En gvSIG se usa el Trac de bugs de OSOR para gestionar los bugs. Cuando se de de alta un bug deberemos rellenar obligatoriamente los campos:

Si alguno de estos campos queda sin valor o están asignado incorrectamente puede que el ticket no sea tratado de forma correcta.

Los campos:

Los dejaremos siempre a None.

Es aconsejable rellenar adecuadamente los campos:

Nunca asignaremos el ticket a nadie. Los responsables de tesing serán los encargados de realizar la asignación al desarrollador que crean adecuado.

En caso de que estemos interesados en abordar la resolución del ticket, añadiremos un comentario indicándolo esperando a que el equipo de testing nos lo asigne.

Enlazar los commits y los tickets

Versión:1.2

Alcance

Este documento cubre las especificaciones a cumplir cuando se realize un commit sobre los proyectos de gvSIG, así como qué debe ponerse en el ticket asociado a ese commit.

Los formatos indicados son específicos para Redmine, que es el sistema de gestión de incidencias y tareas usado actualmente en el proyeto gvSIG (https://devel.gvsig.org/redmine).

Descripción

Cuando un desarrollador realiza un commit sobre una parte de gvSIG que no se encuentra en desarrollo (no hay un proyecto en desarrollo sobre esa parte de gvSIG), deberá añadir, en el mensaje del commit, el número de ticket que describe la nueva funcionalidad o la corrección del bug de ese commit. Para ello utilizará el formato:

#ticket

Donde:

es aconsejable añadir en el comentario del commit, ademas del enlace al ticket un pequeño comentario explicativo de lo que se ha hecho, en general podria valer el titulo del ticket asociado al commit.

Además de poner el mensaje en el commit, deberá incluir como comentario en el ticket, el número de revisión del SVN que arregla ese ticket. El formato del texto a añadir en el comentario sería (ojo con la letra r, es necesaria para indicar que es una revisión):

project:rREVISION-NUMBER

Donde:

Ejemplo:

gvsig-desktop:r38195

En caso de que la resolución del ticket se materialice en varios commits, se añadirá, por cada commit, una línea al comentario con el formato descrito.

Existe un mecanismo que permite, directamente al hacer el commit de un cambio, referenciar o incluso marcar como resuelto un ticket de Redmine. Para ello basta incluir en el comentario del commit lo siguiente:

Este mecanismo es recomendable ya que redmine lo reconoce y muestra de forma más integrada la información de los tickets con las revisiones relacionadas.

Note

Hay que tener en cuenta cuando se usa esta opción que el estado del ticket no se cambiará hasta que alguien acceda al apartado Repositorio del proyecto en el que se encuentra el ticket.

Registro de cambios
versión Descripción
1.1 Añadido nota para que en el comentario del commit seañada al menos el titulo del ticket asociado ademas de su numero.
1.2 Cambiar referencias a OSOR por Redmine, actualizar formatos de comentarios e indicar mecanismo de auto-cerrado de tickets desde commit.

Qué debo hacer para corregir un bug

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:

En caso de que se cumplan favorablemente estas condiciones:

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:

Registro de cambios
versión Descripción