Nota: L'originale è più recente di questa traduzione.

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

La segnalazione del bug può essere fatta da un qualsiasi utente con un normale messaggio di posta elettronica a [email protected] contenente nel corpo del messaggio una riga Package (per maggiori informazioni consultare Segnalazione di bug). Successivamente alla segnalazione verrà associato un numero, verrà inviata una risposta all'utente che ha fatto la segnalazione e infine verrà inoltrato a debian-bugs-dist. Se nella riga Package è indicato un pacchetto con un manutentore allora anch'egli riceverà una copia del 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. Un bug può anche essere chiuso da qualsiasi collaboratore se il bug riguarda un pacchetto orfano o se il manutentore del pacchetto non è riuscito a chiuderlo. È molto importante menzionare la versione in cui è stato corretto il bug. 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[email protected]. 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[email protected] 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 aperto e la mailing list debian-bugs-closed riceveranno ciascuna una notifica riguardo il cambio dello status del bug. Colui che l'ha aperto 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.

Qualunque sviluppatore che voglia rispondere ad una segnalazione può semplicemente rispondere al messaggio, senza cambiare il campo Reply-To. Questo non chiuderà la segnalazione.

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 [email protected].

Perché i messaggi siano aggiunti nel sistema di tracciamento dei bug, possono essere inviati ai seguenti indirizzi:

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 istruzioni 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 per il prossimo rilascio.

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, wontfix, moreinfo, unreproducible, help, security, upstream, pending, confirmed, ipv6, lfs, d-i, l10n, newcomer, a11y, ftbfs, fixed-upstream, fixed, fixed-in-experimental, potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental, sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore . Di seguito alcune informazioni dettagliate sui tag:

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
Il manutentore ha richiesto aiuto per occuparsi di questo bug. Da usare nel caso che il manutentore non abbia le conoscenze per correggere questo bug e desidera la collaborazione di qualcuno oppure se è già carico di lavoro e vuole delegare questa attività. Questo bug non è adatto per i novellini a meno che non anche sia stato marcato anche con il tag newcomer.
newcomer
Questo bug ha una soluzione nota e il manutentore richiede che qualcun altro la implementi. Questo è il compito ideale per i novellini che desiderano contribuire a Debian o per coloro che vogliono migliorare le proprie capacità.
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.
a11y
Questo bug è pertinente all'accessibilità di utenti con disabilità. Impatta particolarmente l'usabilità da parte di persone che fanno affidamento su tecnologie assistive (o altre tecnologie adattative) per usufruire del sistema o del pacchetto.
ftbfs
Fallisce la compilazione del pacchetto dai sorgenti. Se il bug è assegnato a un pacchetto sorgente allora fallisce la compilazione del pacchetto; se il bug è assegnato a un pacchetto binario allora rigurda il fallimento della compilazione dei pacchetti sorgente. L'etichetta è applicabile agli ambienti di compilazione non-standard (per esempio l'uso di Build-Depends da experimental) tuttavia in questi casi la gravità dovrebbe essere inferiore a serious (release critical).
potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch, buster, bullseye, bookworm, trixie, forky, sid, experimental
Questi sono un tag relativi ad una distribuzione e hanno due effetti. Quando sono applicato su una segnalazione, il bug può solo essere relativo a un particolare rilascio (e può avere a che fare anche con altre distribuzioni se ci sono i relativi tag) e vengono utilizzate le normali regole buggy/fixed/absent. Inoltre la segnalazione non può essere archiviata finché non viene risolta nella distribuzione.
sarge-ignore, etch-ignore, lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore, stretch-ignore, buster-ignore, bullseye-ignore, bookworm-ignore, trixie-ignore forky-ignore
Questo è un bug release-critical ma può essere ignorato con lo scopo di arrivare al rilascio della distribuzione. Questo tag deve essere utilizzato solo dai manager dei rilasci; non usate questo tag senza il loro permesso esplicito.

Di seguito alcune informazioni sui tag specifici per distribuzione: 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 ([email protected]) 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 o degli autori del pacchetto e che il campo Cc contenga sia l'indirizzo di chi ha fatto la segnalazione, sia nnn[email protected], sia nnn@bugs.debian.org.

Chiedi all'autore di mantenere il campo Cc con nnn[email protected] 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 aggiungi 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 [email protected].

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 [email protected] 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 [email protected].

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 il Debian Package Tracker. 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[email protected]. 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[email protected]. 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 [email protected] 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 reinviati 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 <[email protected]>

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