¡Esta es una revisión vieja del documento!


Sistema de seguimiento de errores

Objetivo

El sistema de seguimiento de errores tiene dos objetivos: localizar y corregir errores y gestionar la solititud de nuevas funcionalidades.

Esta es la forma más eficaz de garantizar la corrección de errores: Mientras que un error conocido no haya sido corregido aparece en el bugtracker. Gracias a este sistema se hace imposible olvidarse de ellos.

Las solicitudes de nuevas características o mejoras también se gestionan desde el bugtracker. Aunque para ello no resulte el sistema ideal, resulta verdaderamente práctico utilizar la misma herramienta para la resolución de errores.

Descripción del sistema

El sistema de seguimiento de errores está basado en Mantis. Esta herramienta dispone de multitud de útiles herramientas, por ejemplo, poder generar de forma automática listas de errores corregidos y funciones añadidas para una versión de Piwigo determinada ver en acción.

Porqué no se usa el foro para tal cometido?

La diferencia entre el foro y el bugtracker es el nivel de especialización. Aunque el foro es una herramienta de análisis muy genérica, el bugtracker está dedicado a los tiquets de seguimiento (corrección de problemas o petición de características). Si estuviéramos usando el foro oara el seguimiento de errores, los usuarios tendrían que ser mucho más metódicos con cada proceso. Con el bugtracker, la herramienta marca la pauta al usuario de forma precisa para realizar cada proceso. Los usuarios sólo tienen que rellenar un conjunto completo de información y seguir el proceso establecido.

Uno de los propósitos de la bugtracker es mantener información útil y relevante a largo plazo.

Lo que podemos hacer con el bugtracker no podemos llevarlo a cabo con el foro:    * Sigue el estado de un error    * Informa de quién es el encargado de arreglarlo    * Informa quién está interesado en cada error (cualquiera puede suscribirse a un error)    * Informa en qué versión se ha correjido un error

Utilización

Reglas

Para los que reportan los errores

  • Registrarse es obligatorio para poder reportar errores, pero no para poder consultarlos. El bugtracker, el foro y la wiki no comparten las cuentas de usuario.
  • Al informar de un problema, ser precisos y rellenar tantos campos como os sea posible.
  • Indicar vuestra versión es útil solamente si reportáis errores. No es necesario hacerlo para la petición de nuevas características. Al informar de un error en versiones en desarrollo (trunk), indicar la versión o la revisión de Subversión.

Para los programadores

  • Target version. Establecer “target version” para características, no para errores. target version debe ser una versión “superior”, como “Butterfly” (que se convirtió en 1.8.0) o Alligator (que se convirtió en 1.7.0), y no la 1.7.2 (en la cuál no se planeó la adición de características en una rama de versión estable. Si no se ha decidido planificar una característica para una versión mayor, no debe establecerse la “target version”. Sólo significa que la función no se encuentra en la hoja de ruta (roadmap).
  • Cuando un programador resuelve/cierra un error, se procede a introducir la mejora en la revisión de la Sebversión en la que ha sido aplicada.

Estado del problema (Issue status)

Errores

+--------------+
|     new      | (nuevo) enviado y notificado a los programadores
+--------------+
       |
+--------------+
|   feedback   | (respuesta) el problema está en espera de comentarios (discussion session)
+--------------+
       |
+--------------+
|   confirmed  | (confirmado) el error puede reproducirse y está en espera de un programador
+--------------+
       |
+--------------+
|   assigned   | (asignado) un programador se encarga de dicho error
+--------------+
       |
+--------------+
|   resolved   | (resuelto) El error está reparado en la rama correspondiente a la versión informada
+--------------+
       |
+--------------+
|    closed    | (cerrado) la corrección al error está aplicada al trunk
+--------------+

Petición de características

+--------------+
|      new     | (nuevo) enviado y notificado a los programadores
+--------------+
        |
+--------------+
|   feedback   | (respuesta) el problema está en espera de comentarios (discussion session)
+--------------+
        |
+---------------
| acknowledged | (reconocido) solicitud de característica aprobada y en espera de programador
+--------------+
        |
+--------------+
|   assigned   | (asignado) un programador se encarga de dicho error
+--------------+
        |
+--------------+
|    closed    | (cerrado) la corrección al error está aplicada al trunk
+--------------+
 
Ir hasta arriba
acerca_de/sistema_de_seguimiento_de_errores.1368979859.txt.gz · Última modificación: 2013/05/19 16:10 por albertparera
 
 
github twitter newsletter Donar Piwigo.org © 2002-2024 · Contacto