Informazioni sul sistema per la gestione dei bug a uso dei manutentori di pacchetto e di chi si occupa del triage

All'inizio la descrizione del bug è inviata da un qualsiasi utente come un normale messaggio a submit@bugs.debian.org. Successivamente verrà associato un numero a questa segnalazione, rispondendo all'utente che l'ha segnalata, e inviandolo a debian-bugs-dist. Se l'utente ha inserito una linea Package e se il pacchetto ha un gestore allora anch'egli riceverà il messaggio.

La linea Subject avrà in aggiunta Bug#nnn:, e la Reply-To sarà cambiata per includere sia l'utente che segnala il problema, sia il gestore, sia nnn@bugs.debian.org.

Chiusura delle segnalazioni

Le segnalazioni di bug dovrebbero essere chiuse quando si elimina il problema. Un problema si considera risolto quando il pacchetto che include la soluzione viene immesso nell'archivio Debian.

Normalmente gli unici che dovrebbero chiudere una segnalazione sono la persona che ha fatto la segnalazione e il manutentore del pacchetto verso il quale è stata inviata la segnalazione. Ci sono eccezioni a questa regola, per esempio quando il pacchetto non è specificato oppure per certi pseudo-pacchetti. Se si è in dubbio anziché chiudere la segnalazione conviene chiedere nella lista di messaggi debian-devel.

Le segnalazioni dovrebbero essere chiuse inviando un email a nnn-done@bugs.debian.org. Il testo del messaggio deve contenere una spiegazione di come il problema è stato risolto.

Con tutti i messaggi inviati dal sistema di tracciamento, per chiudere una segnalazione è sufficiente rispondere al messaggio con un qualsiasi programma di posta elettronica e modificare il campo To per dire nnn-done@bugs.debian.org al posto di nnn@bugs.debian.org (nnn-close è fornito come alias per nnn-done).

Laddove possibile è meglio utilizzare la linea Version nello pseudo-header del proprio messaggio quando si sta chiudendo una segnalazione, in modo che il sistema sappia quale versione contiene la correzione del problema.

La persona che chiude un bug, la persona che l'ha aperta e la mailing list debian-bugs-closed riceveranno ciascuna una notifica riguardo il cambio dello status del bug. Colui che l'ha aperta e la mailing list riceveranno inoltre il contenuto del messaggio spedito a nnn-done.

Messaggi di Followup

Il sistema di tracciamento dei bug includerà l'indirizzo del segnalatore e quello del bug (nnn@bugs.debian.org) nel campo Reply-To dopo aver rigirato la segnalazione. Nota che questi sono due indirizzi diversi.

Se uno sviluppatore vuole rispondere ad una segnalazione egli può semplicemente rispondere al messaggio, senza cambiare il campo Reply-To. Questo non chiuderà la segnalazione.

Il sistema di tracciamento riceverà il messaggio a nnn@bugs.debian.org, lo passerà a chi mantiene il pacchetto, lo memorizzerà con tutti gli altri log per quel bug e lo invierà a debian-bugs-dist.

Inviare un email a nnn-submitter@bugs.debian.org invierà esplicitamente l'email al segnalatore e memorizzerà una copia del messaggio nel sistema. Il messaggio non verrà inviato al manutentore del pacchetto.

Se vuoi spedire un messaggio followup che non consideri appropriato per debian-bugs-dist puoi spedirlo a nnn-quiet@bugs.debian.org o nnn-maintonly@bugs.debian.org. I messaggi inviati a nnn-quiet@bugs sono registrati nel sistema di tracciamento dei bug ma non sono inviati ad alcuna persona o lista di messaggi. I messaggi inviati a nnn-maintonly@bugs.debian.org sono registrati e inviati anche al gestore del pacchetto in questione.

Non usare mai la possibilità rispondi a tutti o followup offerta dal programma di posta a meno che tu non intenda cambiare poi a mano la lista dei destinatari. In particolare vedi di non spedire messaggi a submit@bugs.debian.org.

Per maggiori informazioni su intestazioni e sulle risposte soppresse e su come inviare copie conoscenza usando il sistema di tracciamento dei bug, vedere istruzioni per segnalare bug.

Livelli di gravità

Il sistema registra un livello di gravità del bug. In maniera predefinita viene assegnato il livello normal, ma questo può essere impostato inserendo una linea Severity nello pseudo-header quando il bug viene segnalato (vedi le istruzione per segnalare i bug ), o utilizzando il comando severity nel server per il controllo delle segnalazioni.

I livelli di gravità sono:

critical
si riferisce a problemi che bloccano il pacchetto o l'intero sistema; oppure causano la perdita di dati importanti; oppure introducono dei problemi di sicurezza sui sistemi nei quali installi il pacchetto.
grave
rende il pacchetto in questione inusabile o quasi; oppure causa la perdita di dati; oppure introduce dei problemi di sicurezza legati agli utenti del pacchetto.
serious
indica una seria violazione della policy Debian (vale a dire di tutto quello che è identificato come must o required) o che comunque secondo il manutentore del pacchetto, o il manager di rilascio, rende lo stesso inappropriato per il rilascio.
important
un bug che abbia un effetto pesante sull'usabilità del pacchetto, senza però renderlo inusabile per tutti.
normal
il valore predefinito, utilizzabile per i bug normali.
minor
un bug che non inficia l'usabilità del pacchetto e che è facile da correggere.
wishlist
per ogni richiesta di cambiamento del programma non legata a bug.

Alcuni livelli sono considerati release-critical, vale a dire che il problema avrà un certo impatto nell'inserire il pacchetto nella versione stabile di Debian. Attualmente questi livelli sono critical, grave e serious. Per le regole complete che definiscono quali problemi meritino questo tag si faccia riferimento all' elenco dei problemi release-critical di Lenny.

Tag per le segnalazioni

Ogni bug può avere zero o più insiemi di tag. Questi tag sono mostrati nella lista dei bug quando si guarda la pagina del package e quando si guarda al log completo.

I tag possono essere creati inserendo una linea Tags nello pseudo-header quando la segnalazione è inviata (vedi le istruzioni per inviare segnalazioni), o usando il codice comando tags con il control request server. I tag vanno separati con una virgola e/o degli spazi.

I tag attuali sono:

patch
Una patch o altra semplice procedura che sistema il problema è presente nel log. Se la patch fornita non elimina in maniera completa il bug allora questo tag non dovrebbe essere utilizzato.
wontfix
Questo bug non sarà eliminato. Ad esempio perché ci sono più modi per fare delle cose e il manutentore preferisce un modo che non presenta il bug. Oppure perché cambiando il comportamento si avrebbero altri effetti, magari peggiori.
moreinfo
Questo bug non può essere affrontato perché le informazioni non sono sufficienti. La segnalazione verrà ignorata a meno che chi l'ha segnalata non fornisca ulteriori informazioni entro qualche mese. Questo è per segnalazioni del tipo non funziona. Cosa non funziona?
unreproducible
Questo bug non è riproducibile dal manutentore. È richiesta quindi l'assistenza di altre persone per la diagnosi del problema.
help
Lo sviluppatore ha richiesto aiuto per occuparsi di questo bug.
pending
Una soluzione per questo problema è stata trovata e un nuovo pacchetto verrà inviato al più presto.
fixed
Questo bug è stato risolto (tramite un NMU, ad esempio), ma rimane qualcos'altro da terminare prima di rilasciare una nuova versione del pacchetto. Questo tag sostituisce il vecchio livello di severità "fixed".
security
Questa segnalazione indica un problema legato alla sicurezza (cioé permessi errati che ammettono l'accesso a dati che non dovrebbero essere accessibili; superamento dei limiti di array che permettono l'accesso a livello di controllo del sistema (buffer overflow); attacchi "denial of service" che devono essere sistemati, ...). La maggior parte delle segnalazioni relative alla sicurezza dovrebbero avere il livello "critical" o "grave".
upstream
Questo bug riguarda la parte originaria del pacchetto.
confirmed
Il manutentore ha verificato e compreso il problema, ma non lo ha ancora corretto. (L'uso di questo tag è opzionale; è stato pensato per i manutentori che hanno un gran numero di segnalazioni aperte).
fixed-upstream
Questo bug è stato corretto dall'autore del programma, ma non è stato ancora incluso nel pacchetto (per una qualsiasi ragione: magari è troppo complicato portare quelle modifiche oppure si tratta di migliorie minori).
fixed-in-experimental
Il bug è stato corretto nel pacchetto della distribuzione "experimental", ma non ancora in quella "unstable".
d-i
Questa segnalazione è relativa allo sviluppo del debian-installer. Questo tag sarà utilizzato quando il bug è relativo alla procedura di installazione, ma non lo è di nessuno dei pacchetti usati dalla procedura stessa.
ipv6
Questa segnalazione è relativa al supporto per Internet Protocol versione 6.
lfs
Questa segnalazione è relativa al supporto per i file grandi (maggiori di 2 gigabyte).
l10n
Questo bug è pertinente alla localizzazione del pacchetto.
potato
Questo segnalazione riguarda la distribuzione potato di Debian.
woody
Questo segnalazione riguarda la distribuzione woody di Debian.
sarge
Questo è un tag relativo ad una distribuzione e ha due effetti. Quando è posto su una segnalazione, il bug può solo essere relativo a sarge (anche se può avere a che anche con altre distribuzioni se ci sono i relativi tag) e altrimenti le normali regole buggy/fixed/absent vengono utilizzate. Inoltre la segnalazione non può essere archiviata finché non viene risolta in sarge.
sarge-ignore
Questo bug è release-critical ma sarà ignorato con lo scopo di arrivare al rilascio di sarge. Questo tag deve essere utilizzato solo dal manager dei rilasci; non usate questo tag senza il suo permesso esplicito.
etch
Questo è un tag relativo ad una distribuzione e ha due effetti. Quando è posto su una segnalazione, il bug può solo essere relativo a etch (anche se può avere a che anche con altre distribuzioni se ci sono i relativi tag) e altrimenti le normali regole buggy/fixed/absent vengono utilizzate. Inoltre la segnalazione non può essere archiviata finché non viene risolta in etch.
etch-ignore
Questo bug è release-critical ma sarà ignorato con lo scopo di arrivare al rilascio di etch. Questo tag deve essere utilizzato solo dal manager dei rilasci; non usate questo tag senza il suo permesso esplicito.
lenny
Questo è un tag relativo ad una distribuzione e ha due effetti. Quando è posto su una segnalazione, il bug può solo essere relativo a lenny (anche se può avere a che anche con altre distribuzioni se ci sono i relativi tag) e altrimenti le normali regole buggy/fixed/absent vengono utilizzate. Inoltre la segnalazione non può essere archiviata finché non viene risolta in lenny.
lenny-ignore
Questo bug è release-critical ma sarà ignorato con lo scopo di arrivare al rilascio di lenny. Questo tag deve essere utilizzato solo dal manager dei rilasci; non usate questo tag senza il suo permesso esplicito.
squeeze
Questo è un tag relativo ad una distribuzione e ha due effetti. Quando è posto su una segnalazione, il bug può solo essere relativo a squeeze (anche se può avere a che anche con altre distribuzioni se ci sono i relativi tag) e altrimenti le normali regole buggy/fixed/absent vengono utilizzate. Inoltre la segnalazione non può essere archiviata finché non viene risolta in squeeze.
squeeze-ignore
Questo bug è release-critical ma sarà ignorato con lo scopo di arrivare al rilascio di squeeze. Questo tag deve essere utilizzato solo dal manager dei rilasci; non usate questo tag senza il suo permesso esplicito.
sid
Questo è un tag relativo ad una distribuzione e ha due effetti. Quando è posto su una segnalazione, il bug può solo essere relativo a sid (anche se può avere a che anche con altre distribuzioni se ci sono i relativi tag) e altrimenti le normali regole buggy/fixed/absent vengono utilizzate. Inoltre la segnalazione non può essere archiviata finché non viene risolta in sid.
experimental
Questo è un tag relativo ad una distribuzione e ha due effetti. Quando è posto su una segnalazione, il bug può solo essere relativo a experimental (anche se può avere a che anche con altre distribuzioni se ci sono i relativi tag) e altrimenti le normali regole buggy/fixed/absent vengono utilizzate. Inoltre la segnalazione non può essere archiviata finché non viene risolta in experimental.

Il significato degli ultimi 8 tag specifici per una distribuzione, è stato modificato di recente: i tag '-ignore' sono pensati per permettere la propagazione alla fase di test; quelli 'release' vogliono indicare che non è possibile archiviare una segnalazione fintanto che il bug non è stato trovato e corretto in quella distribuzione. I tag 'release' indicano anche che il bug è presente solo in quelle distribuzioni, vale a dire che il bug non è presente nelle distribuzioni per le quali quel bug non ha il tag 'release'.

I tag 'release' non dovrebbero essere necessari se la gestione delle versioni del bug permette già di chiarire quali distribuzioni ne siano affette. L'utilizzo delle versioni è da preferire perché non richiede un intervento manuale. Nel caso di dubbi sull'utilizzo dei tag 'release' contattare gli amministratori del BTS (owner@bugs.debian.org) oppure il "release team" per un consulto.

Registrazione di segnalazione esterna a Debian

Quando uno sviluppatore manda la segnalazione a chi gestisce il pacchetto originario (e non quello Debian), dovrebbe inserire il fatto all'interno del sistema per la gestione dei bug.

Assicurati che il campo To del tuo messaggio contenga solo l'indirizzo dell'autore odegli autori del pacchetto e che il campo Cc contenga sia l'indirizzo di chi ha fatto la segnalazione, sia nnn-forwarded@bugs.debian.org, sia nnn@bugs.debian.org.

Chiedi all'autore di mantenere il campo Cc con nnn-forwarded@bugs.debian.org quando risponderanno, così il sistema inserirà la sua risposta all'interno della segnalazione originaria. Questi messaggi vengono registrati ma non inoltrati; per inviare l'email aggiugi ai destinatari nnn@bugs.debian.org.

Quando il sistema riceve un messaggio indirizzato a nnn-forwarded segnerà che il bug è stato comunicato agli indirizzi nel campo To del messaggio che riceve, a meno che il messaggio non sia già stato inoltrato (forwarded).

Puoi modificare quest'ultima informazione spedendo un messaggio a control@bugs.debian.org.

Cambiare il proprietario

Nei casi in cui chi deve risolvere il problema non è il curatore del pacchetto associato (per esempio quando il pacchetto è gestito da un gruppo di persone), può essere utile registrare questo fatto nel sistema di gestione dei bug. Per aiutare in questa operazione ogni bug può avere opzionalmente un proprietario.

Il proprietario può essere impostato inserendo una linea Owner nello pseudo-header della segnalazione (cfr: come segnalare bug), o utilizzando i comandi owner e noowner del control request server.

Manutentori di pacchetto elencati erroneamente

Se il gestore di un pacchetto è erroneamente nella lista il fatto è normalmente spiegato da un recente cambio di gestore, e il nuovo gestore non ha ancora inserito una nuova versione del pacchetto con la segnalazione del cambio nel campo Maintainer del file di controllo. Questo problema viene automaticamente risolto quando il pacchetto è inviato a Debian; in alternativa un manutentore di pacchetto può sovrascrivere il file del manutentore direttamente a mano, per esempio se non è previsto un rebuild e un nuovo upload in tempo breve. Contatta override-change@debian.org per cambiare il file in questione.

Riapertura, diverso assegnamento e gestione delle segnalazioni

È possibile assegnare una segnalazione ad un altro pacchetto, o anche riaprire segnalazioni chiuse per errore, o ancora modificarne le informazioni relative a dove una certa segnalazione va inviata. È anche possibile cambiare il livello di gravità della segnalazione o il titolo stesso, o cambiarne il proprietario, o fondere/separare delle segnalazioni, o inserire le versioni dei pacchetti che sono affette dal bug o che non lo sono. Tutto questo è fatto inviando un messaggio a control@bugs.debian.org.

Il formato di questi messaggi è descritto in un altro documento disponibile sul web nel file bug-maint-mailcontrol.txt. Una versione del documento in solo testo è ottenibile inviando un messaggio con il solo testo help al server all'indirizzo di cui sopra.

Iscrizione ad un bug

Il sistema di tracciamento dei bug permette ai segnalatori, agli sviluppatori e altri interessati, di iscriversi a singole segnalazioni. Questa proprietà può essere utilizzata da quelli che vogliono dare un'occhiata al bug, senza che si debbano iscrivere al pacchetto tramite PTS. Tutti i messaggi inviati a nnn@bugs.debian.org vengono spediti agli iscritti.

Per iscriversi ad un bug si deve inviare un email a nnn-subscribe@bugs.debian.org. L'oggetto e il corpo del messaggio sono ignorati dal BTS. Una volta che il messaggio è processato, all'utente viene inviato un messaggio di conferma al quale è necessario rispondere prima che che i messaggi del bug vengano inviati.

È anche possibile annullare l'iscrizione ad un bug. Lo si fa inviando un email a nnn-unsubscribe@bugs.debian.org. L'oggetto e il corpo del messaggio sono ignorati dal BTS. Una volta che il messaggio è processato, all'utente viene inviato un messaggio nel quale si chiede la conferma dell'annullamento.

Normalmente l'indirizzo utilizzato è quello che si trova nel campo From dell'intestazione del messaggio. Se si volesse iscrivere un altro indirizzo, lo si deve codificare nel messaggio di iscrizione secondo questo modello: nnn-subscribe-localpart=example.com@bugs.debian.org. Questo esempio invierà a localpart@example.com il messaggio di conferma per il bug nnn. Il simbolo @ deve essere codificato cambiandolo in =. Analogamente gli annullamenti dell'iscrizione vanno fatti con un email a nnn-unsubscribe-localpart=example.com@bugs.debian.org. In entrambi i casi l'oggetto e il corpo dell'email verranno copiati nel messaggio che richiede la conferma.

Feature più o meno vecchie riguardo all'analisi dell'oggetto

I messaggi che arrivano a submit o bugs e il cui Oggetto comincia con Bug#nnn verranno trattati come se fossero stati inviati a nnn@bugs.debian.org. Questo sia per compatibilità con i messaggi inviati al vecchio indirizzo sia per catturare tutti i messaggi erroneamente inviati a submit (per esempio facendo un 'rispondi a tutti'.)

Una gestione analoga è fatta per maintonly, done, quiet e forwarded, che trattano i messaggi che arrivano con Oggetto simile a quello di prima. Questi messaggi vengono riinviati all'indirizzo nnn-eccetera@bugs.debian.org.

I messaggi che arrivano a forwarded e done — vale a dire senza alcun numero di segnalazione nell'indirizzo — e senza numero di segnalazione nell'oggetto saranno mantenuti solo per alcune settimane.

Caratteristica vecchia: X-Debian-PR: quiet

Una volta era possibile impedire al sistema di fare il forward di un messaggio ricevuto all'indirizzo debian-bugs, inserendo la linea X-Debian-PR: quiet nell'intestazione del messaggio.

Questa linea è ormai ignorata. Per ottenere lo stesso scopo il messaggio va indirizzato a quiet o nnn-quiet (o maintonly o nnn-maintonly).

Altre pagine BTS (sistema di gestione delle anomalie)

Debian BTS administrators <owner@bugs.debian.org>

Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd, 1994-1997 Ian Jackson.