Translation(s): English - Italiano

(!) ?Discussion



Come usare il sistema di Bug Tracking

Seminario online tenuto da Gerfried Fuchs, 09-Dec-2010

Questa è una guida all'uso del Sistema di Bug Tracking (BTS).

L'acronimo BTS sta per Bug Tracking System ed è dove debian conserva e traccia i bug riportati ( incluse le liste sulle feature desiderate(wishlist), che non sono veri e propri bug). È principalmente un sistema di posta elettronica -attualmente infatti migliorarlo e ritoccarlo può essere fatto solamente mandando e-mail al sistema.

Requisiti

Requisiti tecnici:

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 puoi interrogare tutte le segnalazioni sui bug piuttosto rapidamente ( a meno che il server non sia troppo carico ) ed è anche estremamente conveniente.

Se vai su http://bugs.debian.org/ verrai reindirizzato ad una pagina che offre un form dal qualche puoi eseguire delle ricerche -ma la parte più utile sono i vari reindirizzamenti che offre.

Ricordati però che questo tiene conto solo delle segnalazioni per i pacchetti binari.

* se tu hai il numero della segnalazione di un bugpuoi andare direttamente alla segnalazione dello stesso aggiungendo il numero all'URL, come ad esempio http://bugs.debian.org/12345

La pagina panoramica ti permette di avere il ragruppamento delle segnalazioni dei bug con i link all'interno della pagina, e sotto, un altro form che ti aiuta a cambiare la vista per quanto riguarda diversi aspetti.

In più, tieni a mente che sulla pagina panoramica ci sono dei carratteri piuttosto cripticidopo la breve descrizione. è sufficiente posizionare il mouse su di loro per ottenere un suggerimento, e si può cliccare su di loro per far aprire un pop-up contente ulteriori informazioni sul bug in questione.

Questo è il riassunto breve sull'interfaccia web. Come ho detto, è solo una interfaccia di query. Quindi sentitevi liberi di cliccare in giro, esplorare completamente il sito - non può accadere nulla di male.

Segnalare i bug: reportbug

Per la segnalazione dei bug hai bisogno di un cliente di posta elettronica, più convenientemente, usare lo strumento reportbug. reportbug è principalmente un programma testuale ( ma ci sono due interfacce: urwid e altre scritte in GTK+) c'è 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 in locale (Mail Transport Agent) come postfix, exim, o ssmtp. Non voglio entrare nei dettagli su come devono essere configurati, in realtà è molto utile per alcuni averne uno localmente in modo da poter scrivere mail sul proprio computer portatile quando sono offline e inviarle quando tornano di nuovo online.

Anche se quando non si dispone di un MTA locale, la segnalazione dei bug, è ancoramolto utile. Perchè ha l'opzione --template. Questo vi aiuterà a produrre informazioni per la segnalazione di bug che il manutentore del pacchetto avrebbe altrimenti richiesta in ogni caso, come le informazioni sulle dipendenze o simili.

Basta lanciare nel terminale:

reportbug --template package

con il nome del pacchetti che hai installato. Non preoccuparti, non fa nulla di pericoloso, mostra solo alcune righe di testo :)

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

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

Il submit@bugs è dove le nuove segnalazioni vengono mandate. Ovviamente nella tua segnalazione dei inserire un utile e descrittivo titolo che dia al package manager una prima idea su quale sia il problema.

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

I primi tre (grave, critical and serious) sono considerati versione critica e definiscono un speciale gruppo di segnalazioni. Se sei in dubbio, non usarli almeno che non tu non sia sicuro di cosa significhino, alcune persone potrebbero reagire nervosamente se vengono utilizzate segnalazioni che alla fine non sono tanto gravi. Tornerò sull'argomento del significato delle versioni critiche più tardi.

whishlist è la gravità per il miglioramento che vorresti vedere in un pacchetto. Alcuni maintainer di pacchetti potrebbero suggerirti di segnalarli direttamente all'upstream - anche se personalmente ritengo che i maintainer di pacchetti debbano fungere dal tramite tra i nostri utenti e gli sviluppatori upstream.

In fine ricordati, prova ad essere descrittivo non solo nel titolo del bug, ma anche nel corpo della segnalazione, e sarebbe fantastico anche se tu segnalassi il modo per riprodurre il tuo bug.

Per la segnalazione dei bug, c'è altra documentazione a questo 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:

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 migliorarerà immensamente la loro leggibilità. ;)