• Diff for "it/HowtoUseBTS"

Translation(s): it

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:

• 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 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.

• Se tu sei un maintainer di pacchetti, puoi andare all'indirizzo http://bugs.debian.org/tuo@indiriz.zo e vedere le segnalazioni ( lasciate in sospeso ) dei bug di tutti i tuoi pacchetti mantenuti, con l'indirizzo email che usi.

• Se tu sei dall'altra parte segnalatore di rapporti ( e spero che tu non abbandoni i bug che trovi, dopo un po' di tempo, nel caso in cui non vengano corretti subito ) vai a http://bugs.debian.org/from:tuo@indiriz.zo per vedere tutte le tue segnalazioni di bug che non sono stati corretti.

• Se vuoi segnalare un nuovo bug devi controllare prima se il bug è già stato riportato. Per fare questo la pagina http://bugs.debian.org/packagename offre una panoramica per tutte le segnalazioni sui bug per il pacchetto dato.

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

• Se vuoi vedere una segnalazione combinata per tutti i pacchetti binari creati dallo stesso pacchetto sorgente, come ad esempio openoffice.org devi andare invece all'indirizzo http://bugs.debian.org/src:openoffice.org (nota il prefisso :src).

* 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

reportbug --template package

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

• Le linee Package: e Version: devono essere le prime linee della tua segnalazione, all'interno del corpo dell'email dove solitamente scrivi Caro amico,.

• La linea Severity: è opzionale, puoi lasciare vuota se si trotta di una "normale" segnalazione

  severity può avere diversi livelli di importanza, da grave, critical, serious, fino a important e da normal a minor e whishlist.

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

 command bugnumber arguments

retitle 12345 new-title

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.

Like mentioned earlier, feel free to click around - this includes clicking on the version graphs. This will immensely enhance readability of them.