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.
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
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.
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.
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.
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:
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.
| Versión: | 1.2 |
|---|
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).
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:
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. |
| Version: | 1.0 |
|---|
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.
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.
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:
Podremos abordar la resolución del 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.
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:
| versión | Descripción |
|---|---|