I BTS distribuiti  non hanno un database centrale, copiando quindi la logica dei vari programmi di gestione delle versioni (VCS, da Version Control system) distribuiti come git, mercurial, darcs etc.

Come i VCS distribuiti si contrappongono ai VCS centralizzati per la mancanza di un repository cerntrale dove vengono memorizzare le revisioni e così via, allo stesso modo i BTS (Bug Tracking System) distribuiti non hanno un unico database in cui vengono memorizzate le richieste e i bug.

Potremmo dire che se un software tipo bugzilla o flyspray è il compagno ideale di CVS o subversion, un BTS distribuito è il compagno ideale di Git o Bazaar.

Finita questa breve premessa, vediamo di passare ad analizzare gli eventuali vantaggi e svantaggi di questi sistemi, tenendo presente che ovviamente non è un’analisi completa.

Dopo aver valutato diversi sistemi di BTS distribuiti, la mia scelta è caduta su Bugs Everywere, per due semplici ragioni:

• è scritto in python
• si integra meglio di altri con git (almeno per me)

A dire il vero, il primo lo si vede da sè, mentre il secondo nasce dall’uso. L’altro candidato era Ditz. Altri sistemi ci sono, ma non mi hanno impressionato.

Come per i VCS distribuiti il vantaggio maggiore è quello di poter fare tutto off-line. Si può quindi ad esempio aggiungere un bug, modifcarne un altro e chiuderne un terzo senza il bisogno di essere on-line. Questo è il completamento ideale per un VCS tipo git, in quanto rende indipendente lo sviluppatore dall’essere sempre on-line anche per il lato BTS.

Ovviamente ci sono anche degli svantaggi: ad esempio, sono mediamente più complessi da usare per l’utente finale, visto che di solito hanno un’interfaccia testuale e accompagnano i sorgenti (e non gli eseguibili).

Una cosa interessante è che i repository dei bug vengono generalmente trattati come dei qualsiasi file del progetto e quindi i vari elenchi possono essere gestiti in maniera naturale.

Tutti i problemi sono però superabili in un modo o in un altro. Ad esempio Ditz ha un generatore di pagine html statiche per consentire di pubblicare lo stato del progetto via web.

Come ho già  detto la mia scelta è caduta su Bugs Everywere, con il quale traccio i bug di Chiamami (una semplice agenda telefonica).

Il vantaggio principale di BE è la migliore integrazione con git (il VCS che uso), anche se a scapito di una peggiore interfaccia rispetto a Ditz.

Guida veloce a Bugs Everywhere

Adesso una veloce e minuscola guida all’uso di BE per la gestione di un progetto. Lanciando BE senza parametri otteniamo l’elenco dei comandi supportati.

galactica:~/Devel/Test2> be
Bugs Everywhere - Distributed bug tracking

Supported commands
be assign      Assign an individual or group to fix a bug
be close       Close a bug
be comment     Add a comment to a bug
be diff        Compare bug reports with older tree
be help        Print help for given subcommand
be list        List bugs
be new         Create a new bug
be open        Re-open a bug
be remove      Remove (delete) a bug and its comments
be set         Change tree settings
be set-root    Assign the root directory for bug tracking
be severity    Show or change a bug's severity level
be show        Show a particular bug
be status      Show or change a bug's status
be target      Show or change a bug's target for fixing
galactica:~/Devel/Test2>

Si nota abbastanza facilmente che sono abbastanza simili a quelli di un qualsiasi BTS tradizionale.

Un problema che ho riscontrato (ma forse sono io che sbaglio) è che mentre ovviamente non esistono elenchi di target predisposti al contrario di status e severity, non c’è un modo di avere l’elenco dei target già presenti, e questo su progetti un pò più grandi del piccolo progetto personale potrebbe essere un problema. Dopo un rapido scambio di mail con l’autore, questa funzionalità verrà inserita in una prossima versione.

Inizializzare il repository

Partendo dal presupposto di avere già un repository git, per inizializzare il repository be si usa il comando

be set-root

e se tutto va bene il sistema ritorna

galactica:~/Devel/Test2> be set-root
Using git for revision control.
Directory initialized.
galactica:~/Devel/Test2>

Si può notare che BE riconosce automaticamente il fatto che si usa git.

Una nota: il repository git deve avere nella sezione config i valori si user.name e user.email settati, altrimenti il comando fallisce.

Lavorare con i bug

Per aggiungere un nuovo issue, si usa il comando new

galactica:~/Devel/Test2> be new "Test"
Created bug with ID 90c
galactica:~/Devel/Test2>

L’elemento viene creato usando i valori di default del sistema. Creato l’elemento, è possibile modificarlo usando i vari comandi per impostare la gravità, a chi è assegnato, la deadline per la quale si deve chiudere (in termini di versione, ma dato che la versione è una stringa arbitraria, potrebbe anche essere una data) o aggiungere una descrizione più estesa del problema/richiesta.

Ad esempio, per alzare la gravità del bug appena inserito da minor, che è il default, a serious si usa il comando severity

be severity 90c serious

dove 90c è l’id dell’elemento.

Possiamo vedere i dettagli del bug con il comando show

galactica:~/Devel/Test2> be show 90c
          ID : 90cc54c6-d3e3-4562-b340-9c50d8d9ca31
  Short name : 90c
    Severity : serious
      Status : open
    Assigned :
      Target :
     Creator : gian <gian@grys.it>
     Created : Thu, 16 Apr 2009 23:01 (Thu, 16 Apr 2009 21:01:05 +0000)
Test
--------- Comment ---------
Name: 90c:1
From: gian <gian@grys.it>
Date: Thu, 16 Apr 2009 21:11:53 +0000

Aggiungere un commento
galactica:~/Devel/Test2>

.Per chiudere un bug, si usa abbastanza ovviamente il comando close

be close 90c

Se invece abbiamo già un elendo di bug e lo vogliamo visualizzare, allora ci viene in aiuto il comando list

galactica:~/Devel/Test2> be list
90c:os: Test
981:om: Test
galactica:~/Devel/Test2>

Il formato e’ questo:

• 90c indica l’id del bug
• os indica stato e severità del bug
• il resto è il sommario

Questo è tutto quello che serve per poter usare Bugs Everywhere nel lavoro di tutti i giorni.