Document Actions
Guía para "commiters" de gvSIG
- Introducción
- Qué debe saber...
- Cómo dar de alta bugs
- Enlazar los commits y los tickets
- Qué debo hacer para corregir un bug
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
Cómo tiene que dar de alta un bug.
Es importante que conozca cómo tiene que dar de alta un bug. Para ello cuenta con el documento Cómo dar de alta un bug
Mensajes en los commits.
Qué tiene que poner en el mensaje de los commits y qué en los comentarios a un ticket cuando corrige un bug. Puede consultar información relacionada con esto en Enlazar los commits y los tickets.
Corrección de bugs
Qué pasos debe hacer para corregir un bug y qué bugs puede y cuáles no puede corregir. Consulte el documento Qué debo hacer para corregir un bug
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:
version con la versión de gvSIG en la que detectamos el problema.
SubprojectName con el valor que corresponda. Si estamos dando de alta un bug de gvSIG seleccionaremos gvSIG.
SubprojectVersion con la versión adecuada. Si es un bugs de gvSIG le pondremos el mismo valor que en el campo version.
En caso de que se tratase de un bug sobre otro subproyecto, seleccionaremos la versión adecuada de ese subproyecto.
prioridad a 1.
BuildNumber, con el número de build de gvSIG en el que se detecta el problema. En caso de que se haya detectado sobre una versión ejecutada desde un workspace se pondrá el literal DEVEL.
Summary, descripción corta del bug detectado
Detailed description.
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:
- SubprojectResolveVersion
- SubprojectResolveBuildNumber
- Resolution
Los dejaremos siempre a None.
Es aconsejable rellenar adecuadamente los campos:
- SubprojectBuildNumber
- Component
- OperatingSystem
- Severity
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:
- ticket es el número de ticket dentro de Redmine.
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:
- project, es el identificador del proyecto de Redmine en el que reside el SVN en el que se subió el cambio. En general, para gvSIG, será gvsig-desktop.
- REVISION-NUMBER es el número de revisión en el SVN en el que se arregla el ticket.
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:
Para referenciar un ticket:
Refs #ticket
Para marcar un ticket como fixed y poner su % Realizado al 100%:
Fixes #ticket
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.
| 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:
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.
| versión | Descripción |
|---|---|
