Document Actions
Manual del repositorio de extensiones
Este documento explica el procedimiento para dar de alta y gestionar un nuevo proyecto en el nuevo catálogo de extensiones de gvSIG
Antecedentes
Es una necesidad ya vieja del proyecto gvSIG disponer de un lugar en el que dar difusión de los desarrollos y aportaciones que diferentes actores (empresas, universidades, programadores, etc) creen que pueden ser útiles a la comunidad gvSIG.
Este nuevo área del portal de gvSIG servirá como lugar común para la publicación de extensiones y contribuciones no oficiales.
Definiciones
repositorio
Aplicación web que permite catalogar extensiones y aportaciones a gvSIG. Técnicamente es un producto añadido a una instancia del gestor de contenidos Plone.
administrador del repositorio
Persona encargada de gestionar este componente. Su responsabilidad es la de dar de alta usuarios en el sistema y aprobar la publicación de proyectos
proyecto
Desarrollo de una extensión o cualquier otro tipo de aportación con entidad suficiente para ser publicada en el repositorio. El proyecto deberá de contar con alguna presencia en forma de dirección de contacto, preferiblemente con algún tipo de página web y forma de contacto con los desarrolladores y opcionalmente con un repositorio de código fuente, repositorio de errores, etc.
responsable del proyecto
Persona encargada de dar de alta el proyecto en el repositorio, así como punto de contacto entre el equipo gvSIG y la entidad que quiere publicar su proyecto en el repositorio.
release
Con cada nueva versión del proyecto, en el repositorio se pueden configurar diferentes publicaciones (comúnmente denominadas releases) desde versiones inestables a versiones estables.
Requisitos previos
El único requisito técnico para empezar a trabajar con el repositorio es disponer de un usuario y contraseña. Cabe destacar que este usuario no es el mismo que el del portal de gvSIG ya que se tratan de instancias de Plone diferentes.
Por lo tanto, el primer paso es ponerse en contacto con los administradores a través de este formulario .
Creación del proyecto
Una vez validados en el repositorio es sencillo crear un nuevo proyecto pulsando en el botón Add new software project. En este apartado se disponen los datos generales del proyecto. Es decir, los datos compartidos por cualquier release que se pueda hacer:
- Título, resumen y descripción larga del proyecto
- Categoría o categorías a las que pertenece el proyecto
- Versiones de gvSIG en las que se ha testado el proyecto
- Diferentes direcciones (las que procedan):
- URL o dirección de correo electrónico de contacto (única obligatoria)
- Página web del proyecto
- Repositorio de código fuente y de bugs
- Lista de correo
- Imagen del logotipo (para subir o enlazada) y pantallazo (para subir)
Una vez rellenados estos datos, como es habitual en Plone, se solicita la publicación del proyecto. El administrador del repositorio deberá decidir si el proyecto se publica o no.
En general es recomendable que el gestor del proyecto se ponga en contacto con el administrador del repositorio antes de iniciar cualquier trabajo para llevar la coordinación y seguimiento del proyecto desde el principio.
Añadiendo un proyecto al repositorio
Creación de releases
Una vez el administrador del repositorio ha publicado el proyecto, el gestor puede empezar a añadir releases.
Para dar de alta la primera release, la aplicación web muestra un acceso directo en el área para éstas. A partir de ahí basta con entrar en el listado de releases para añadir una nueva.
Los datos que conforman una release son:
- Número de versión y alias
- Descripción corta y completa
- Lista de cambios
- Nombre y correo electrónico del release manager
- Fechas en las que se:
- Dejan de aceptar propuestas de mejoras
- Se dejan de añadir nuevas funcionalidades
- Se espera publicar la release
- Licencia de la aportación. Actualmente se soportan
- GNU GPL
- GNU LGPL
- Versión revisada de la licencia BSD
- Compatibilidad de la extensión con las diferentes versiones de gvSIG (1.0 en adelante)
- Lista de cambios aceptados (ver más adelante)
- Rama del repositorio del código fuente para la release
Únicamente son obligatorios los campos de versión, descripción corta y licencia.
Añadiendo una release al proyecto
Añadir ficheros a una release
Con la release creada, ya es posible añadirle ficheros. Estos pueden ser ficheros que subamos al repositorio o bien enlaces a un servidor externo. Para hacer esto en la pantalla de la release deberemos pulsar en el menú superior derecho agregar un nuevo ítem->{downloadable file|externally hosted file}.
Al añadir un fichero se indican nombre y plataformas sobre las que dicho fichero es operativo.
ATENCIÓN: Actualmente no se soporta por parte del proyecto gvSIG la subida de ficheros, por lo que estos obligatoriamente deberán estar alojados en un servidor externo. Cualquier fichero subido a los servidores del proyecto será borrado.
Menú para añadir ficheros a una release
Estados de la release
unreleased
Una vez creada la release, esta se encuentra sin publicar (unreleased). Esto no significa que no sea visible al público, sino que es una versión en la que se está trabajando y por lo tanto todavía no debería disponer de binarios o distribuibles que puedan ser considerados ni siquiera una versión preliminar (aunque esta situación se puede dar ya que el sistema lo permite).
Durante esta fase se podría gestionar las peticiones de cambios como más adelante se verá y en general proponer fechas para publicación, comentarios, etc.
alpha, beta, release candidate, final release
Diferentes estados típicos en la publicación de binarios en el ámbito del software libre. Estos estados se establecen de la forma habitual en Plone con el menú superior derecho.
Gestión del roadmap del proyecto
Si el gestor del proyecto lo estima oportuno, puede utilizar el repositorio como centro de gestión del roadmap y las características de su proyecto. Es decir, puede catalogar las características que espera añadir a su proyecto en futuras releases y asignarlas, discutirlas, aceptar comentarios, etc. desde el propio repositorio.
Editando las propiedades del roadmap (y los tipos de propuestas)
Propuestas de mejora
Para ello debe acceder al roadmap del proyecto y añadir la propuesta desde el menú agregar improvement proposal. Los campos a rellenar en una propuesta de mejoras son:
- Título y resumen de la propuesta
- Nombre del proposer y si hay alguien que apoya la propuesta (seconder).
- Tipo de propuesta (los tipos se mantienen desde la pantalla de edición del roadmap)
- Motivación
- Descripción completa de la propuesta
- Definiciones
- Asunciones
- Detalles de la implementación
- Productos a generar a partir de la propuesta
- Riesgos
- Lista de actuaciones para resolver la propuesta de mejora
- Participantes
- Rama del código fuente en el que se está realizando la tarea
Las entradas para el título, resumen, proposer, tipo, motivación y descripción larga de la propuesta son obligatorias.
Añadiendo una propuesta de mejora
Ejemplo de presentación de una propuesta
Estados de una propuesta de mejora
Una propuesta de mejora se crea en estado de borrador (draft). En cualquier momento el gestor del proyecto la puede pasar a propuesta (propose) con lo que quedará abierta a discusión (discussed).
Sólo usuarios validados podrán discutir (comentar) la propuesta de mejora.
Una propuesta en discusión puede rechazarse (reject), indicar que se han iniciado los trabajos (begin work) o bien posponerla (defer work).
En general se trata de un flujo básico de gestión de las propuestas que permiten realizar un mantenimiento sencillo de las mismas.
Al crear la release, como se ha comentado anteriormente, se asignan las características que se van a cubrir en dicha release.
Extensión de ejemplo
En la actualidad existe una extensión dada de alta en el sistema que ha servido como banco de pruebas para este manual. Esta extensión tiene una descripción con prácticamente todos los campos rellenos así como una release y diversas propuestas de mejora.
