• Diff for "it/HowtoUseBTS"

Come usare il sistema di tracciamento dei bug (BTS)

Seminario online organizzato da Debian Women e tenuto su IRC da Gerfried Fuchs, 09-Dec-2010

Questa è una guida all'uso del Sistema di tracciamento dei bug (BTS, Bug Tracking System).

L'acronimo BTS sta per Bug Tracking System ed è dove Debian conserva e traccia i bug segnalati (incluse le segnalazioni delle funzionalità desiderate (wishlist), che non sono veri e propri bug). È principalmente un sistema di posta elettronica: infatti controllarlo e manipolarlo può essere fatto solamente mandando e-mail al sistema.

Requisiti

Requisiti tecnici:

• reportbug, il programma bts dal pacchetto devscripts.

Interrogare le segnalazioni sui bug: l'interfaccia web di BTS

L'interfaccia web di BTS può essere trovata all'indirizzo http://bugs.debian.org/. Attraverso questo portale si possono interrogare le segnalazioni sui bug piuttosto rapidamente (a meno che il server non sia troppo carico) ed è anche estremamente comodo.

Andando su http://bugs.debian.org/ si verrà reindirizzati ad una pagina che offre un modulo dal quale si possono eseguire delle ricerche, ma la parte più utile sono i vari reindirizzamenti che offre.

• I maintainer di pacchetti, possono andare all'indirizzo http://bugs.debian.org/tuo@indiriz.zo e vedere le segnalazioni (ancora aperte) dei bug di tutti i pacchetti che mantengono usando quell'indirizzo email.

• Se si segnalano bug (e si spera che chi trova dei bug non li tenga per sé, diventando sempre più irritato col passare del tempo perché non vengono risolti) si può andare su http://bugs.debian.org/from:tuo@indiriz.zo per vedere tutte le proprie segnalazioni di bug che non sono ancora state risolte.

• Se si desidera segnalare un nuovo bug, si deve prima controllare se il bug è già stato riportato. Per fare questo la pagina http://bugs.debian.org/nomepacchetto offre una panoramica di tutte le segnalazioni di bug per il pacchetto dato. Si noti però che questa pagina riporta solo le segnalazioni per i pacchetti binari.

• Se si desidera vedere un rapporto combinato sui bug di tutti i pacchetti binari creati dallo stesso pacchetto sorgente, come ad esempio openoffice.org, si deve andare invece all'indirizzo http://bugs.debian.org/src:openoffice.org (si noti il prefisso :src).

• Se si ha il numero della segnalazione di un bug si può andare direttamente a quella segnalazione aggiungendo il numero alla fine dell'URL, come ad esempio http://bugs.debian.org/12345.

Nelle pagina panoramica ci sono tutti i gruppo principali delle segnalazioni dei bug con i link all'interno della pagina e, in fondo alla pagina, un altro modulo che aiuta a cambiare la vista per quanto riguarda diversi aspetti.

In più, si noti che sulla pagina panoramica ci sono dei caratteri piuttosto criptici dopo la descrizione breve di una segnalazione di bug. È sufficiente posizionare il mouse su di loro per ottenere un suggerimento, e si può cliccare su di loro per far aprire una finestra a comparsa contente ulteriori informazioni sul bug in questione.

Questo è un riassunto breve sull'interfaccia web. Come è stato detto, è solo una interfaccia di interrogazione. Quindi ci si può sentire liberi di cliccare in giro, esplorare completamente il sito: non può accadere nulla di male.

Segnalare i bug: reportbug

Per la segnalazione dei bug è necessario un programma di posta elettronica oppure, cosa molto più comoda, si può usare lo strumento reportbug. reportbug è principalmente uno strumento testuale (ma ci sono due interfacce grafiche: basate su urwid e GTK+), esiste anche reportbug-ng che è un'interfaccia grafica che mira a fare lo stesso lavoro, ma è comunque uno strumento differente.

Entrambi hanno bisogno di un MTA (Mail Transport Agent) in locale come postfix, exim o ssmtp. Non si entrerà nei dettagli su come devono essere configurati, in realtà è molto utile per alcuni utenti averne uno localmente in modo da poter scrivere posta elettronica sul proprio computer portatile quando non collegati e questa verrà inviata quando la connessione sarà ristabilità.

Anche quando non si dispone di un MTA locale, reportbug è ancora molto utile dato che ha l'opzione {--template}}}. Questo aiuterà a produrre informazioni per la segnalazione di bug che il manutentore del pacchetto richiederebbe in ogni caso, come le informazioni sulle dipendenze o simili.

Basta lanciare nel terminale:

reportbug --template pacchetto

con il nome di un pacchetto che è installato. Non ci si preoccupi, non fa nulla di pericoloso, mostra solo alcune righe di testo

Ci sono diverse cose importanti che daranno un'idea su cosa fare, come a chi inviare le e-mail:

To: Debian Bug Tracking System <submit@bugs.debian.org>

L'indirizzo submit@bugs è dove vengono mandate le nuove segnalazioni. Ovviamente nella segnalazione si deve inserire un titolo utile e descrittivo che dia al manutentore del pacchetto una prima idea su quale sia il problema.

Poi c'è un altro blocco che comincia con Package:, ha una riga Version: e una Severity::

• Le righe Package: e Version: devono essere le prime nella segnalazione, all'interno del corpo dell'email dove solitamente si scrive Caro amico,.

• La riga Severity: è opzionale, la si può lasciare vuota se si tratta di una "normale" segnalazione.

  severity, che segnala la severità di un bug, può avere diversi livelli prefissati, da grave, critical, serious, passando per important e normal fino ad arrivare a minor e wishlist.

I primi tre (grave, critical e serious) sono considerati critici per il rilascio e definiscono un speciale gruppo di segnalazioni. Se si è in dubbio, non usarli almeno che non si sia sicuri del loro significhato, alcune persone potrebbero reagire nervosamente se vengono utilizzati per segnalazioni che alla fine non sono tanto gravi. Si ritornerà sul significato speciale delle segnalazioni di bug critici per il rilascio più tardi.

wishlist è la gravità usata per i miglioramenti che si vorrebbero vedere in un pacchetto. Ci si prepari al fatto che alcuni manutentori di pacchetti potrebbero suggere di segnalarli direttamente agli autori originali; anche se, personalmente, l'autore di guesta guida ritiene che i manutentori di pacchetti debbano fungere da collegamento e da tramite tra gli utenti Debian e gli sviluppatori originali.

In fine, è bene ricordare che si deve cercare di essere descrittivi non solo nel titolo del bug, ma anche nel corpo della segnalazione e sarebbe fantastico se si segnalasse anche il modo per riprodurre il bug.

Per la segnalazione dei bug, c'è altra documentazione all'indirizzo http://www.debian.org/Bugs/Reporting.

Ottimizzare le segnalazioni dei bug: control@bugs.debian.org

Per ottimizzare le segnalazioni dei bug, c'è l'indirizzo email control@bugs.debian.org. L'intero sistema di bug tracking è aperto a chiunque, come è questo indirizzo mail. Questo significa che qualsiasi persone è tecnicamente abile per ottimizzare qualsiasi segnalazione di bug. L'indirizzo di controllo è dove inizia il divertimento. Funziona come l'indirizzo per la segnalazione nelle prime linee.

La documentazione per questo indirizzo puoi trovarla a: http://www.debian.org/Bugs/server-control

Normalmente la sintassi è:

 command bugnumber arguments

Il numero di argomenti varia a seconda dei comandi:

Quindi con retitle:

retitle 12345 new-title

imposti il titolo della segnalazione da 12345 a new-title.

Non preoccuparti, non può essere fatto per questo numero di segnalazione, il bug è già stato archiviato. Puoi ottimizzare solo le segnalazioni non ancora archiviate.

Un comando solitamente usato è reassign per asseggnare un bug ad un altro pacchetto. Questo comando prende il secondo argomento dopo il nome del pacchetto: Il numero di versione. Se tu sai quale è la versione dell'altro pacchetto affetto dal bug è davvero utili aggiungere la versione così il tracciamento continuerà il suo lavoro. Spiegerò il tracciamento di versione dopo, I will explain version tracking a bit later, ho fatto alcuni esempi per semplificare la sua comprensione.

Il comando tag ti aiuta a classificare i bug. Arrualmente segnalando i bug puoi aggiungere anche Tags: agli pseudo header e specificare i tags per una segnalazione.

Molti tag regolarmenti usati sono:

• patch: quando aggiungi una patch con la tua mail

• moreinfo e unreproducible: quando i maintainer hanno problemi a capire l'origine del problema

• security: quando il bug è un problema di sicurezza.

La lista dei tag può essere consultata su: http://www.debian.org/Bugs/Developer#tags.

Se vuoi iscriverti ad una specifica segnalazione, manda una mail a bugnumber-subscribe@bugs.debian.org. Riceverai una mail che richiede la conferma della iscrizione, da questo punto in poi riceverai tutte le mail mandate a quella segnalazione. Puoi anche iscriverti alle segnalazioni di uno specifico pacchetto attraverso il PTS (Package Tracking System) a http://packages.qa.debian.org/NOMEPACCHETTO. In basso a sinistra troverai il form di iscrizione.

Ma se una persona manda una mail sia a control@bugs che a bugnumber@bugs naturalmente non vuoi confondere il control parser con il testo che hai aggiunto al package maintainer. Per questo motivo c'è un comando speciale thanks che ti permette di essere avvertito dopo comandi del controller. Questo dice al parser di fermare il parsing dell'email da quel punto in poi.

Prendi nota che le email mandate a bugnumber@bugs arrivano al maintainer del pacchetto (e le persone sottoscritte ad esso). Queste email NON vengono mandate alle persone che segnalano i bug! Questo è anche qualcosa che è in discussione da cambiare - per il momento, c'è bisogno o di scovare il mittente della segnalazione del bug e aggiungerlo esplicitamente alle copie, o, per praticità, utilizzare un altro indirizzo di posta elettronica:bugnumber-submitter@bugs.debian.org.

Tracciamento di versione

Cos'è il tracciamento di versione? BTS tiene traccia di quale versione di una bug è stata chiusa, quali altre release colpisce, ecc. Per questo lo pseudo-header Version: è molti importante nella segnalazione di un bug. Anche se il BTS potrebbe invece pensare che colpisce solo una determinata versione del pacchetto.

Ed è anche il posto dove trovare il gruppo speciale release-critical bugs di cui ho parlato prima. Perchè le segnalazioni vengono archiviate dopo 28 giorni sempre che soddisfino determinati criteri: di norma quelli che vengono corretti sia in unstable sia in testing vanno in archivio.

Naturalmente solo se questi affliggono entrambe le release -una segnalazione può coprire anche solo unstable -se è stato creato un pacchetto per tutte le architetture.

Quindi la distribuzione colpita è un criterio, per le architetture è un altro. Se entrambi i criteri solo risolti, il timer comincia.

Le segnalazioni posso essere chiuse i molti modi. Quello più comune è un pacchetto caricato che contiene, ad esempio, closes: #12345 nel changelog. Quando il pacchetto è accettato nell'archivio viene mandata una mail a 12345-done@bugs.debian.org con Version: 1.2.3 nella prima linea dell'mail. Questo ovviamente può essere fatto a mano, si può mandare una mail a -done@bugs con l'header Version: che informa della chiusura del bug in quella versione.

Se la segnalazione è un "non problema" (come, una falsa segnalazione), l'header Version: non dovrà essere aggiunto alla mail.

Questa differenza è richiesta perchè il BTS deve essere in grado di distinguere i bug corretti di una specifica versione che non sono bug reali.

Il BTS ha una feature davvero molto utile: Il grafo di versione. Potresti averlo già notato in alcuni report di bug, nell'angolo in alto a destra. Si compone di vari riquadri: quello rotondo rosso e verde quello quadrato. Quelli verdi sono quelli di versioni fisse, quelle rosse sono quelle versioni interessate.

Come già detto in precedenza, non esitare a cliccare in giro, anche sui grafi di versione. Questo migliorerà immensamente la loro leggibilità.