Introduzione al server di posta di controllo e gestione bug

Così come request@bugs.debian.org permette di ottenere informazioni su segnalazioni e documentazione via email, control@bugs.debian.org permette di manipolare in vari modi i rapporti sui bug.

Il server di controllo lavora proprio come il server di richiesta, tranne per alcuni comandi addizionali; di fatto, è lo stesso programma. I due indirizzi sono separati solo per evitare che gli utenti commettano degli errori e causino problemi mentre provano solo a richiedere informazioni.

Poiché i comandi del server di controllo vanno a cambiare lo stato di una segnalazione, un email di notifica viene mandato ai curatori dei pacchetti coinvolti. Inoltre il messaggio inviato al server e le modifiche effettuate vengono registrate nella segnalazione e sono quindi disponibili tramite le pagine WWW.

Leggi la introduzione al server di richiesta disponibile sul World Wide Web, nel file bug-log-mailserver.txt, o invia help a uno dei server di posta, per i dettagli sulle basi operative dei server di posta e i comandi comuni disponibili inviando mail a entrambi gli indirizzi.

La scheda di riferimento per i server di posta è disponibile via WWW, in bug-mailserver-refcard.txt o inviando una mail e usando il comando refcard.

Comandi disponibili sul server di posta di controllo

Generale	Versioni	Duplicati	Altro
reassign severity tags retitle submitter	found \| notfound fixed \| notfixed reopen	merge \| unmerge forcemerge clone	thanks # forwarded \| notforwarded owner \| noowner block \| unblock archive \| unarchive

reassign bugnumber pacchetto [ versione ]

Registra che il bug #bugnumber è un bug in pacchetto. Questo può essere usato per impostare il pacchetto se l'utente ha dimenticato la pseudo-intestazione, o per modificare una assegnazione precedente. Nessuna notifica è inviata ad alcuno (a parte l'usuale informazione nella traccia del processo).

Se si fornisce la versione, il sistema di tracciamento ricorderà che il bug è relativo a qualla versione del pacchetto al quale si sta facendo l'assegnamento.

Si può assegnare una segnalazione a due pacchetti in un solo comando separando i nomi dei pacchetti con una virgola. Ciononostante questo va fatto solo se il problema può risolto uno qualsiasi dei due pacchetti. In tutti gli altri casi si deve fare il clone della segnalazione e assegnarne la copia all'altro pacchetto.

reopen bugnumber [ originator-address | = | ! ]

Riapre #bugnumber se è stato chiuso.

In maniera predefinita, o se specifichi =, il mittente originale è ancora l'originatore del rapporto, cosicché otterrà la notifica quando sarà chiuso nuovamente.

Se fornisci un originator-address l'originatore sarà impostato all'indirizzo fornito. Se volessi diventare il nuovo originatore del rapporto riaperto puoi usare la forma abbreviata ! o specificare il tuo indirizzo email.

È generalmente una buona idea dire alla persona che viene registrata come originatore che stai riaprendo il rapporto del bug, cosicché sappia di doversi aspettare una notifica quando sarà chiuso di nuovo.

Se il bug non è chiuso, la reopen non farà nulla, nemmeno il cambio di originatore. Per cambiare l'originatore di una segnalazione aperta si deve usare il comando submitter; si noti che questo avviserà l'originatore precedente del cambio.

Se il bug è stato segnato per essere chiuso in una versione particolare del pacchetto, ma riappare in una successiva è meglio utilizzare il tag found anziché questo.

found bugnumber [ versione ]

Segna che il bug numero bugnumber è stato riscontrato in una certa versione del pacchetto al quale è assegnato.

Il sistema di tracciamento dei bug usa questa informazione con quella che riguarda la versione nel quale il bug è stato risolto, per mostrare l'elenco dei bug aperti nelle varie versioni del pacchetto. Un bug viene considerato aperto se nessuna versione lo risolve o quando è stato ritrovato in versioni più recenti rispetto a quella di chiusura.

Se non viene specificata la versione allora l'elenco delle versioni corrette viene azzerato. Questo è lo stesso comportamento che si ha con reopen.

Questo comando marcherà la segnalazione come non chiusa se non viene specificata alcuna versione; oppure se la versione marcata è la stessa versione che è stata marcata fixed per ultima. (Se si è certi di non voler chiudere la segnalazione, utilizzare reopen con found.)

Questo comando è stato introdotto in sostituzione di reopen perché non era possibile modificare quest'ultimo aggiungendogli il parametro versione senza ambiguità.

notfound bugnumber versione

Cancella la registrazione che il bug numero bugnumber sia presente nella versione versione del pacchetto al quale è assegnato.

Questo differisce rispetto alla chiusura del problema perché il bug non risulta corretto nella versione specificata o in altre. In futuro non ci saranno informazioni sul bug in quella versione del pacchetto. È stato pensato per correggere eventuali segnalazioni errate.

fixed bugnumber versione

Indica che il bug numero bugnumber è stato corretto nella versione del pacchetto al quale è assegnato.

Questo non causa la chiusura della segnalazione, ma aggiunge solamente un'altra versione nel quale il bug è corretto. Usare numerobug-done per chiudere la segnalazione e marcare il problema come corretto in una specifica versione.

notfixed bugnumber versione

Cancella l'indicazione che il bug numero bugnumber sia stato risolto nella specifica versione.

Questo comando è equivalente al comando found seguito dal comando notfound (il found rimuove il fixed in una versione specifica, mentre il notfound rimuove il found).

submitter bugnumber indirizzo-di-originatore | !

Cambia l'originatore del #bugnumber in indirizzo-di-originatore.

Se si voglia diventare nuovo originatore di una segnalazione si può utilizzare l'abbreviazione ! o specificare il proprio indirizzo email.

Nonostante il comando reopen cambi l'originatore delle segnalazioni unite a quella riaperta, submitter non influisce sulle segnalazioni unite.

forwarded bugnumber indirizzo

Notifica che bugnumber è stato reinviato per conoscenza al upstream maintainer presso indirizzo. Questo non invia materialmente il rapporto. Può essere usato per modificare un esistente indirizzo di forwarded-to, o registrarne uno nuovo per un bug che non era stato in precedenza annotato come inviato per conoscenza.

notforwarded bugnumber

Dimentica qualsiasi idea che bugnumber sia stato inviato per conoscenza a un qualche upstream maintainer. Se il bug non era stato registrato come inviato per conoscenza, non farà nulla.

retitle bugnumber nuovo-titolo

Modifica il titolo di un rapporto di bug in quello specificato (il default è l'intestazione Subject) dal rapporto originale.

Contrariamente alla maggior parte degli altri comandi di gestione dei bug, quando usato su uno dei rapporti di un insieme di rapporti collegati (merged), questo cambierà solo il titolo del bug individuale richiesto e non tutti quelli collegati con esso.

severity bugnumber gravità

Imposta il livello di gravità del rapporto bug #bugnumber a gravità. Nessuna notifica viene inviata all'utente che ha riportato il bug.

Le gravità sono critical, grave, serious, important, normal, minor, e wishlist.

Per il loro significato consulta la documentazione generale dello sviluppatore per il sistema dei bug.

clone bugnumber new ID [ new IDs ]

Il comando di controllo clone permette di duplicare una segnalazione. È utile quando una singola segnalazione indica vari bug. New IDs sono numeri negativi, separati da spazi, che possono essere utilizzati nei comandi successivi per riferirsi al bug clonato. Per ogni ID viene generata una nuova segnalazione.

Esempio di utilizzo:

        clone 12345 -1 -2
        reassign -1 foo
        retitle -1 foo: foo sucks
        reassign -2 bar
        retitle -2 bar: bar sucks when used with foo
        severity -2 wishlist
        clone 123456 -3
        reassign -3 foo
        retitle -3 foo: foo sucks
        merge -1 -3

merge bugnumber bugnumber ...

Collega due o più rapporti su bug. Quando i rapporti sono collegati aperture, chiusure, marcature e demarcature come reinviati e riassegnazioni di uno dei bug a un nuovo pacchetto avranno un identico effetto su tutti gli altri collegati.

Prima che dei bug possano essere collegati devono trovarsi esattamente nello stesso stato: tutti aperti o tutti chiusi, con il reinvio allo stesso indirizzo di autore upstream o tutti non marcati come reinviati, tutti assegnati allo stesso pacchetto o pacchetti (un confronto di stringa esatto viene fatto su tutti i pacchetti ai quali il bug è assegnato), e tutti con la medesima gravità. Se non partissero tutti dallo stesso stato dovresti usare reassign, reopen e così via per essere sicuro che lo siano prima di usare merge. Non è necessario che i titoli corrispondano e non saranno modificati dal merge. Neanche i tag devono corrispondere e, anzi, verranno uniti.

Se uno dei bug elencati in un comando merge è già collegato con un altro bug, tutti i rapporti collegati con uno qualsiasi di quelli elencati saranno collegati insieme. Il collegamento è come l'uguaglianza: è riflessiva, transitiva e simmetrica.

Il collegamento di rapporti causa l'apparizione di una nota in ciascun log di rapporto; sulle pagine WWW questo causa l'inclusione dei link agli altri bug.

I rapporti collegati sono tutti fatti spirare contemporaneamente, e solo quando tutti i rapporti rispettano i criteri di eliminazione ciascuno separatamente.

forcemerge bugnumber bugnumber ...

Forza il collegamento tra due o più segnalazioni. Il primo viene elencato come principale e le sue caratteristiche (quelle che devono corrispondere per il merge) vengono assegnate alle altre segnalazioni. Per evitare sviste, è necessario che tutte le segnalazioni siano relative allo stesso pacchetto. Leggere il testo precedente per informazioni sul significato di merge.

Nota che questo rende possibile la chiusura di una segnalazione tramite il merge; sei quindi responsabile della notifica al segnalatore con un messaggio che notifichi la chiusura della segnalazione.

unmerge bugnumber

Disconnette un rapporto su bug da qualsiasi altro con il quale possa essere stato collegato. Se il rapporto indicato è collegato con diversi altri questi sono lasciati tutti collegati fra loro; solo le loro associazioni con il bug esplicitamente indicato sono rimosse.

Se molti rapporti su bug sono collegati e vuoi separarli in due gruppi di rapporti collegati devi scollegare ciascun rapporto in uno dei nuovi gruppi separatamente e quindi collegarli nel richiesto gruppo nuovo.

Puoi scollegare un solo rapporto con ogni comando unmerge; se vuoi scollegare più di un bug semplicemente includi un serie di comandi unmerge nel tuo messaggio.

tags bugnumber [ + | - | = ] tag [ tag ... ]

Imposta un particolare tag per il rapporto su bug #bugnumber al valore tag. Nessuna notifica è inviata all'utente che ha riportato il bug. + significa aggiungi, - significa sottrai, e = significa ignora i tag correnti e impostali da zero. L'azione di default è aggiungi.

Esempio d'uso:

        # eguale a 'tags 123456 + patch'
        tags 123456 patch

        # eguale a 'tags 123456 + help security'
        tags 123456 help security

        # aggiunge i tag 'fixed' e 'pending'
        tags 123456 + fixed pending

        # elimina il tag 'unreproducible'
        tags 123456 - unreproducible

        # imposta esattamente i tag 'moreinfo' e 'unreproducible'
        tags 123456 = moreinfo unreproducible

I tag attualmente disponibili includono patch, wontfix, moreinfo, unreproducible, help, pending, fixed, fixed-in-experimental, fixed-upstream, security, upstream, confirmed, d-i, ipv6, lfs, l10n, potato, woody, sarge, sarge-ignore, etch, etch-ignore, sid e experimental.

Per i loro significati consulta la documentazione generale dello sviluppatore per il sistema dei bug.

block bugnumber by bug ...

Segnala che la soluzione di questo bug è bloccata da un altro.

unblock bugnumber by bug ...

Segnala che la soluzione di questo bug non è più bloccata da un altro.

close bugnumber [ fixed-version ] (sconsigliato)

Chiude il rapporto sul bug #bugnumber.

Una notifica viene inviata all'utente che ha riportato il bug, ma (in contrasto all'invio di una mail a bugnumber-done@bugs.debian.org) il testo della mail che ha causato la chiusura del bug non è incluso in questa notifica. Il manutentore che chiude un rapporto dovrebbe assicurarsi, probabilmente inviando un messaggio separato, che l'utente che ha riportato il bug sappia del perchè sia stato chiuso. L'uso di questo comando è pertanto sconsigliato. Vedere le altre informazioni per gli sviluppatori su come chiudere una segnalazione correttamente.

Se si fornisce una versione in fixed-version, il sistema di tracciamento noterà che il bug è stato corretto in quella versione.

package [ nomepacchetto ... ]

Limita il campo di azione dei comandi successivi ai soli pacchetti elencati. Si può elencare uno o più pacchetti. Se non si nomina alcun pacchetto i comandi successivi avranno azione su tutti i pacchetti. Si è incoraggiati ad utilizzare questo comando come misura cautelativa nel caso si utilizzi il numero di bug errato.

        package foo
        reassign 123456 bar 1.0-1

        package bar
        retitle 123456 bar: bar sucks
        severity 123456 normal

        package
        severity 234567 wishlist

owner numerobug indirizzo | !

Imposta indirizzo come "proprietario" del #numerobug. Il proprietario di una segnalazione è quello che si prende la responsabilità di risolverlo. È utile per condividere il lavoro se il pacchetto ha un gruppo di manutentori.

Se si vuole diventare il proprietario del bug, si può usare il ! come scorciatoia o specificare il proprio indirizzo email.

noowner numerobug

Elimina tutte le tracce di altri proprietari del bug al di fuori del manutentore ufficiale. Se non ci sono proprietari già memorizzati allora nulla cambia.

archive numerobug

Archivia una segnalazione che era stata già archiviata in passato a condizione che abbia tutti i requisiti necessari, a parte quello del tempo.

unarchive numerobug

Estrae dall'archivio una segnalazione che era stata precedentemente archiviata. Questa operazione va in genere associata alla riapertura o ai tag found/fixed. Le segnalazioni estratte dall'archivio possono essere riarchiviate con il tag archive anche se non hanno raggiunto il requisito temporale.

#...

Commento di una linea. Il # deve essere all'inizio della riga. Il testo del commento può essere incluso nel messaggio di risposta mandato al mittente e ai manutentori, quindi può essere un modo di documentare il perché dei propri comandi.

quit

stop

thank...

thanks...

thankyou...

thank you...

--...

In una linea a se stante, maiuscolo o minuscolo, anche seguito da spazi. Dice al server di controllo di bloccare l'analisi del messaggio; il resto del messaggio può includere spiegazioni, firma o qualsiasi altra cosa. Nulla di ciò verrà preso in considerazione del server di controllo.

Altre pagine BTS (sistema di gestione delle anomalie)

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