Tenemos sistemas de control de versiones distribuidos (DVCS o DSCM) como git o mercurial, pero el control de bugs (Bug Tracking System) lo tenemos que hacer mediante un sistema centralizado como Bugzilla, Mantis BT, Trac o Redmine. Imaginemos que nos gustaría gestionar nuestros bugs dentro del DSCM, de forma que los bugs acompañaran al código y que no hiciera falta un repositorio central para consultarlos o gestionarlos. Tal vez un directorio concreto donde guardar la información de los bugs actuales y su estado. Pues bien, eso es en esencia lo que Bugs Everywhere nos ofrece.

Bugs Everywhere puede utilizarse con varios DSCM. Según la documentación ahora mismo puede usarse con Arch, Bazaar, Darcs, Git, Mercurial y Monotone. En cualquiera de ellos BE gestiona un directorio (llamado .be/) dentro del directorio principal del repositorio, donde guarda los bugs y su estado, los comentarios, etc. Como el reporte de bugs es distribuido, en vez de números consecutivos se usan identificadores únicos.

La principal manera de usar BE es mediante la herramienta de línea de comandos be, aunque también posee una interfaz web y otra basada en e-mail. Mediante be, podemos inicializar el repositorio de bugs con be init, añadir un nuevo bug con be new, añadir comentarios a los bugs con be comment, listar los bugs con be list, manipularlos, etc. Como véis, es muy similar a cómo se usan git, mercurial y otros DSCM en línea de comandos. Para una rápida introducción podéis echarle un vistazo al tutorial¹.

Bugs Everywhere no es el único BTS distribuido que existe. A raíz de este artículo en LWN, algunos interesados se juntaron en esta página y recopilaron una lista. Lamentablemente, la lista está muy desactualizada, así que he buscado cuáles de ellos todavía existen en los repositorios de Debian. Este es el resultado:

p   bugs-everywhere     - distributed bug tracking system using VCS
p   cil                 - command line issue tracker
p   ditrack             - lightweight distributed issue tracking sys
p   ditz                - distributed issue tracker
p   fossil              - DSCM with built-in wiki, http interface an
p   ikiwiki             - a wiki compiler
p   sd                  - peer-to-peer bug tracker
p   ticgit              - ticketing system built on Git

Todo esto se movió alrededor de 2008, y desde entonces el interés por este tipo de sistemas parece que se ha apagado totalmente. A pesar de haber pasado más de 5 años, ninguno de estos BTS distribuidos ha madurado ni ha surgido ninguna solución a los problemas que presentan. Citando el propio artículo de LWN:

All of this can make distributed bug tracking look like a source of more work for developers, which is not the path to world domination. What is needed, it seems, is a combination of more advanced tools and better integration with the underlying SCM.

Y más abajo:

There is one remaining problem, though, which has not been touched upon yet. A bug tracker serves as a sort of to-do list for developers, but there is more to it than that. It is also a focal point for a conversation between developers and users. Most users are unlikely to be impressed by a message like "set up a git repository and run these commands to file or comment on a bug." There is, in other words, value in a central system with a web interface which makes the issue tracking system accessible to a wider community. Any distributed bug tracking system which does not facilitate this wider conversation will, in the end, not be successful. Creating a distributed tracker which also works well for users could be the biggest challenge of them all.

Y es que si bien el BTS distribuido parece ideal para los desarrolladores (que ya usan este modelo para gestionar el código fuente), no lo es para los usuarios que lo único que quieren es reportar los errores que se encuentran de la forma más sencilla posible.

A mi me parece que se están intentando resolver dos problemas diferentes con el mismo modelo y herramienta: por un lado la interfaz usuarios-desarrolladores, y por el otro la gestión interna de los bugs por los propios desarrolladores. Y aquí es donde se produce el choque entre el modelo centralizado, el mejor para los primeros, y el distribuido, deseable para los segundos. Una solución que reconociera esta dicotomía seguramente sería más adecuada, pero me parece que no existe nada del estilo.

Así que si tu proyecto está orientado a usuarios-desarrolladores (una biblioteca por ejemplo), algo como Bugs Everywhere puede ser ideal, pero si no, si va a tener muchos usuarios que no van a tocar un DSCM ni con un palo de tres metros de largo, es mejor que vayas pensando en un bug tracker centralizado "clásico" para tu proyecto.

:wq