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