Introduzione al server di posta di controllo e gestione bug

Così come [email protected] permette di ottenere informazioni su segnalazioni e documentazione via e-mail, [email protected] permette di manipolare in vari modi i rapporti sui bug.

Nel caso in cui serva scrivere un messaggio relativo al bug e manipolare i suoi metadati, i comandi possono essere inclusi nell'e-mail a [email protected]. Per farlo è necessario iniziare l'e-mail con i comandi preceduti da Control: . Un metodo alternativo è quello di inviare una copia dell'e-mail a [email protected] e scrivere i comandi nell'e-mail con l'aggiunta del comando finale thanks.

Poiché i comandi del server di controllo vanno a cambiare lo stato di una segnalazione, un'e-mail di notifica viene mandata 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 e-mail a entrambi gli indirizzi.

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

Comandi disponibili sul server di posta di controllo

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

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ò essere risolto da una modifica in 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 e cancella tutte le versioni in cui è risolto 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'indirizzo di origine del bug sarà impostato all'indirizzo fornito. Se volessi diventare il nuovo indirizzo di origine del rapporto riaperto puoi usare la forma abbreviata ! o specificare il tuo indirizzo e-mail.

È generalmente una buona idea dire alla persona che viene registrata come indirizzo di origine 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 indirizzo di origine. Per cambiare l'indirizzo di origine di una segnalazione aperta si deve usare il comando submitter; si noti che questo avviserà il proprietario del precedente indirizzo di origine del bug 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. version può essere una versione nella forma nomepacchettosorgente.

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. version può essere una versione nella forma nomepacchettosorgente.

Questo comando marcherà la segnalazione come non chiusa se non viene specificata alcuna versione; oppure se la versione marcata è la stessa o superiore della più alta 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. version può essere una versione nella forma nomepacchettosorgente.

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. version può essere una versione nella forma nomepacchettosorgente.

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. version può essere una versione nella forma nomepacchettosorgente.

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) con l'eccezione che il bug non viene riaperto se la versione trovata è superiore di ogni altra versione in cui sia stato risolto. È stato pensato per correggere eventuali errori di registrazione effettuati dopo aver risolto il bug; nella maggior parte dei casi in realtà si desidererà utilizzare found invece che notfixed.

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 e-mail.

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. indirizzo dovrebbe in generale essere un URI, oppure un indirizzo e-mail. Utilizzando di preferenza URI si permette a strumenti automatici di interrogare sistemi di tracciamento di bug (quali bugzilla) per evidenziare lo stato della segnalazione.

Esempio d'utilizzo:

      forwarded 12345 http://bugz.illa.foo/cgi/54321

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. Verrà cambiato anche il titolo di tutti i rapporti di bug con i quali questo è collegato.

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, wishlist.

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

affects bugnumber [ + | - | = ] package [ package ... ]

Indica che un bug colpisce anche un altro pacchetto. Nel caso in cui bugnumber causi una rottura in package anche se il bug è effettivamente presente nel pacchetto al quale è stato assegnato, ciò farà sì che il bug sia elencato in maniera predefinita nell'elenco dei bug di package. Questo dovrebbe accadere laddove il bug è abbastanza grave da causare segnalazioni multiple dagli utenti che lo assegnano al pacchetto sbagliato. = definisce come affetti dal bug i pacchetti indicati, ed è l'azione predefinita se non vengono specificati pacchetti; - rimuove i pacchetti indicati dalla lista di quelli affetti dal bug; + aggiunge i pacchetti indicati alla lista di quelli affetti dal bug ed è l'opzione predefinita nel caso in cui siano specificati dei pacchetti.

summary bugnumber [message number | summary text]

Seleziona un messaggio da usare come sommario del bug. Il primo paragrafo non-pseudoheader/non-control di tale messaggio viene analizzato e configurato come sommario del bug onde venir poi mostrato in cima alla pagina della segnalazione del bug. Ciò è utile nei casi in cui la segnalazione originale non descrive correttamente il problema oppure il bug contiene un gran numero di messaggi che rendono difficoltoso identificare il reale problema.

Se message number non è fornito, il sommario viene cancellato. message number è il numero del messaggio come elencato nell'output dello script cgi di bugreport; se un viene fornito un message number di 0, viene usato il messaggio presente (ovvero, il messaggio che è stato inviato a [email protected] e che contiene il comando di controllo summary).

Se message number non è un numero né una stringa vuota il sistema lo interpreterà come il testo con il quale configurare il sommario.

outlook bugnumber [message number | outlook text]

Seleziona un messaggio che descriva lo stato di avanzamento della risoluzione del bug (oppure lo stato dell'arte della risoluzione del bug). Il primo paragrafo non-pseudo-header/non-control di tale messaggio è processato e utilizzato come stato dell'arte del bug e viene visualizzato in cima alla pagina della segnalazione. Questo è utile per coordinarsi con altri che stiano lavorando sulla risoluzione dello stesso bug (per esempio, in un bug squashing party).

Quando message number non è indicato, lo stato di avanzamento del bug viene ripulito. message number è il numero del messaggio, così come riportato nell'output dello script cgi della segnalazione del bug; se viene fornito un message number uguale a 0, si continuerà ad utilizzate il messaggio attuale (ovvero il messaggio che è stato inviato all'indirizzo [email protected] contenente il comando outlook).

Se message number non è un numero né una stringa vuota, il sistema lo interpreterà come il testo con il quale configurare lo stato di avanzamento del 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. Le caratteristiche del primo bug elencato (quelle che devono corrispondere per il merge) vengono assegnate alle altre segnalazioni. I tag sono concatenati come sempre. 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 ... ][ + | - | = 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 ciascun tag successivo, - significa sottrai ciascun tag successivo e = significa imposta i tag successivi all'elenco fornito. I +, -, = interposti cambiano l'azione per il tag successivo. L'azione predefinita è 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

	# rimuove il tag 'moreinfo' e aggiunge il tag 'patch'
	tags 123456 -moreinfo + patch

I tag attualmente disponibili includono 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 .

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 un'e-mail a bugnumber[email protected]) il testo dell'e-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 e-mail.

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. Non si dovrebbe usare unarchive per effettuare modifiche banali ai bug archiviati, come ad esempio cambiare l'originatore del bug; lo scopo principale di unarchive è di permettere la riapertura di bug che sono stati archiviati senza dover chiedere l'intervento degli amministratori di BTS.

#...

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