Apéndice B. Gestor de fallos libres

Bugzilla es muy popular, es mantenido activamente, y parece que hace a sus usuarios muy felices. Yo he estado usando una variante modificada de él en mi trabajo desde hace cuatro años, y me gusta. No es altamente personalizable, pero esa puede ser, de una manera curiosa, una de sus características: Las instalaciones de Bugzilla tienden a parecer la misma sea donde sea que se encuentren, lo que significa que muchos desarrolladores estén ya acostumbrados a su interfaz y se sentirán en un territorio familiar.

GNU GNATS es uno de los gestores de fallos de código abierto más antiguos, y se usa extensamente. Su mayor fortaleza reside en la diversidad de interfaces (no solamente puede ser usado a través de un navegador WEB, sino que también a través de correo electrónico o utilidades de línea de comandos), y el almacenamiento de los ejemplares en texto plano. El hecho de que los datos de todos los ejemplares se almacenen en ficheros de texto en el disco hace que sea más fácil escribir herramientas a medida para buscar y analizar sintácticamente los datos (por ejemplo, para generar informes estadísticos). GNATS también puede absorber correos electrónicos de muchas maneras, y añadirlos a los ejemplares apropiados basados en patrones dentro de las cabeceras del correo electrónico, lo que hace que el registro de las conversaciones del usuario/desarrollador sean muy fáciles.

El sitio Web de RT dice que "RT es un sistema de etiquetado de niveles de seguridad que permite a un grupo de gente manejar tareas, ejemplares, y peticiones enviadas por una comunidad de usuarios de una manera inteligente y eficiente, y todo eso en resumen. RT posee una interfaz web bastante pulida, y parece tener una base ampliamente instalada. La interfaz es un poco compleja en términos visuales, pero que llega a ser menos molesto a medida que se utiliza. RT tiene una licencia GNU GPL (por alguna razón, su sitio web no deja esto claro).

Trac es un poco más que un gestor de fallos: realmente es un sistema wiki y gestor de fallos integrado. Usa el enlace Wiki para conectar ejemplares, ficheros, grupos de cambios de control de versión, y simples páginas wiki. Es bastante simple de configurar, y se integra con Subversion (ver Apéndice A, Sistemas de Control de Versiones Libres).

Roundup es bastante fácil de instalar (sólo se necesita Python 2.1 o superior), y simple de usar. Tiene interfaces web, para correo electrónico y de línea de comandos. Las plantillas de datos de ejemplares y las interfaces web son parametrizables, al igual que alguna de su lógica de transición de estados.

Mantis es un sistema de gestión de fallos basado en web, escrito en PHP, y que usa la base de datos MySQL como almacenaje. Posee las características que se esperarían de él. Personalmente, encuentro la interfaz web limpia, intuituva, y visualmente fácil.

Scarab está pensado para ser un gestor de fallos altamente parametizable y con todas las características, ofreciendo más o menos el conjunto total de las características ofrecidas por otros gestores de fallos: entradas de datos, consultas, informes, notificaciones a grupos interesados, acumulación colaborativa de comentarios, y gestión de dependencias.

Se parametriza a través de páginas web administrativas. Se puede tener múltiples "módulos" (proyectos) activos en una única instalación de Scarab. Dentro de un módulo dado, se puede crear nuevos tipos de ejemplares (defectos, mejoras, tareas, peticiones de apoyo, etc.), y añadir atributos arbitrarios, para afinar el gestor a los requisitos específicos de tu proyecto.

Para finales de 2004, Scarab se acercaba a su versión liberada 1.0.

El Sistema de Gestión de Fallos de Debian (Debian Bug Tracking System) es inusual en el sentido que todas las entradas y manipulaciones de ejemplares se hace vía correo electrónico: cada ejemplar obtiene su propia dirección de correo electrónico dedicada. El DBTS escala bastante bien: http://bugs.debian.org/ tiene 227.741 ejemplares, por ejemplo.

Ya que la interacción se hace vía clientes de correo normales, un entorno que es familiar y fácilmente accesible para la mayoría de gente, el DBTS es bueno para manejar grandes volúmenes de informes entrantes que necesitan una rápida clasificación y respuesta. Por supuesto, también existen desventajas. Los desarrolladores deben dedicar el tiempo necesario a aprender el sistema de comando del correo electrónico, y los usuarios deben escribir sus informes de fallos sin un formulario web que los guíe en la elección de la información que hay que escribir. Hay algunas herramientas disponibles para ayudar a los usuarios a enviar mejor sus informes de fallos, tales como el programa de línea de comandos reportbug o el paquete debbugs-el para Emacs. Pero la mayoría de la gente no usará estas herramientas; sólo escribirán correos electrónicos a mano, y podrán o no seguir las pautas para reportar fallos publicadas por su proyecto.

El DBTS tiene una interfaz web de sólo lectura, para ver y consultar ejemplares.

Estos están más orientados hacia la gestión de etiquetas del escritorio de ayuda que a la gestión de fallos de software. Probablemente sería mejor con un gestor de fallos habitual, pero estos se han listado por completitud, y porque posiblemente podría tener proyectos poco comunes para los cuales un sistema de etiquetado de problemas podría ser más apropiado que un gestor de fallos tradicional.

El BTT se situa en algún lugar entre un gestor de etiquetas de problema y un gestor de fallos. Ofrece características de privacidad que son algo inusuales entre los gestores de fallos de código abierto: los usuarios del sistema se clasifican como Plantilla (Staff), Amigo (Friend), Cliente (Customer), o Anónimo (Anonymous), y más o menos los datos son accesibles según la categoría de uno mismo. Ofrece algo de integración con el correo electrónico, una interfaz por línea de comandos, y un mecanismo para convertir correos electrónicos en etiquetas. También posee utilidades para mantener la información no asociada con una etiqueta específica, tal como documentación interna o FAQs.