path: root/italian/Bugs/Developer.wml

#use wml::debian::template title="Debian BTS — informazioni per lo sviluppatore" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
#use wml::debian::translation-check translation="40a57e26c62893be7c80d82f1772999f68d51179" maintainer="Francesca Ciceri"

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

<p>La segnalazione del bug può essere fatta da un qualsiasi utente
con un normale messaggio di posta elettronica a
<code>submit@bugs.debian.org</code> contenente nel corpo del messaggio
una riga <code>Package</code> (per maggiori informazioni consultare
<a href="Reporting">Segnalazione di bug</a>).
Successivamente alla segnalazione verrà associato un numero, verr&agrave;
inviata una risposta all'utente che ha fatto la segnalazione e infine
verrà inoltrato a <code>debian-bugs-dist</code>. Se nella riga
<code>Package</code> è indicato un pacchetto con un manutentore allora
anch'egli riceverà una copia del messaggio.</p>

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

<ul class="toc">
  <li><a href="#closing">Chiusura delle segnalazioni</a></li>
  <li><a href="#followup">Followup dei messaggi</a></li>
  <li><a href="#severities">Livelli di criticità</a></li>
  <li><a href="#tags">Tag per le segnalazioni</a></li>
  <li><a href="#forward">Registrare di essere passati da una segnalazione</a></li>
  <li><a href="#owner">Cambiare il proprietario</a></li>
  <li><a href="#maintincorrect">Manutentori di pacchetto elencati erroneamente</a></li>
  <li><a href="#requestserv">Riaprire, riassegnare e manipolare segnalazioni</a></li>
  <li><a href="#subscribe">Iscrizione ad un bug</a></li>
  <li><a href="#subjectscan">Feature più o meno vecchie riguardo all'analisi dell'oggetto</a></li>
  <li><a href="#x-debian-pr">Caratteristica vecchia: <code>X-Debian-PR: quiet</code></a></li>
</ul>


<h2><a name="closing">Chiusura delle segnalazioni</a></h2>

<p>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.</p>

<p>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 <strong>orfano</strong> 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.</p>

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

<p>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 <code>To</code> per dire
<var>nnn</var><code>-done@bugs.debian.org</code> al posto di
<var>nnn</var><code>@bugs.debian.org</code>
(<var>nnn</var><code>-close</code> è fornito come alias per
<var>nnn</var><code>-done</code>).</p>

<p>Laddove possibile è meglio utilizzare la linea <code>Version</code>
nello <a href="Reporting#pseudoheader">pseudo-header</a> del proprio
messaggio quando si sta chiudendo una segnalazione, in modo che il
sistema sappia quale versione contiene la correzione del problema.</p>

<p>La persona che chiude un bug, la persona che l'ha aperto e la
mailing list <code>debian-bugs-closed</code> 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
<var>nnn</var><code>-done</code>.</p>

<h2><a name="followup">Messaggi di Followup</a></h2>

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

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

<p><em>Non</em> usare mai la possibilità <q>rispondi a tutti</q> o <q>followup</q>
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
<code>submit@bugs.debian.org</code>.</p>

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

<ul>
<li>
<var>nnn</var><code>@bugs.debian.org</code> — questi messaggi sono
inviati anche al manutentore del pacchetto e inoltrati a 
<code>debian-bugs-dist</code>, ma <strong>non</strong> a chi ha segnalato
il bug;
</li>
<li>
<var>nnn</var><code>-submitter@bugs.debian.org</code> — questi messaggi
sono inviati anche a chi ha segnalato il bug e inoltrati a <code>debian-bugs-dist</code>,
ma <strong>non</strong> al manutentore del pacchetto;
</li>
<li>
<var>nnn</var><code>-maintonly@bugs.debian.org</code> — questi messaggi
sono inviati solamente al manutentore del pacchetto, <strong>non</strong>
a chi ha segnalato il bug né a <code>debian-bugs-dist</code>;
</li>
<li>
<var>nnn</var><code>-quiet@bugs.debian.org</code> —  questi messaggi sono
solamente inseriti nel sistema di tracciamento dei bug (come tutti quelli
precedenti), ma <strong>non</strong> vengono mandati a nessun altro.
</li>
</ul>

<p>Per maggiori informazioni su intestazioni e sulle risposte soppresse
e su come inviare copie conoscenza usando il sistema di tracciamento dei
bug, vedere <a href="Reporting">istruzioni per segnalare bug</a>.</p>

<h2><a name="severities">Livelli di gravità</a></h2>

<p>Il sistema registra un livello di gravità del bug. In maniera predefinita
viene assegnato il livello <code>normal</code>, ma questo può
essere impostato inserendo una linea 
<code>Severity</code> nello pseudo-header quando il bug viene
segnalato (vedi le
<a href="Reporting#pseudoheader">istruzioni per segnalare i bug
</a>), o utilizzando il comando <code>severity</code> nel
<a href="#requestserv">server per il controllo delle segnalazioni</a>.</p>

<p>I livelli di gravità sono:

<dl>
<dt><code>critical</code></dt>
<dd>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.</dd>

<dt><code>grave</code></dt>
<dd>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.</dd>

<dt><code>serious</code></dt>
<dd>indica una <a href="$(DOC)/debian-policy/">seria
violazione della policy Debian</a> (vale a dire di tutto
quello che è identificato come <q>must</q> o <q>required</q>) o che comunque
secondo il manutentore del pacchetto, o il manager di rilascio, rende lo stesso 
inappropriato per il rilascio.</dd>

<dt><code>important</code></dt>
<dd>un bug che abbia un effetto pesante sull'usabilità del
pacchetto, senza però renderlo inusabile per tutti.</dd>

<dt><code>normal</code></dt>
<dd>il valore predefinito, utilizzabile per i bug normali.</dd>

<dt><code>minor</code></dt>
<dd>un bug che non inficia l'usabilità del pacchetto e che è
facile da correggere.</dd>

<dt><code>wishlist</code></dt>
<dd>per ogni richiesta di cambiamento del programma non legata a bug.</dd>
</dl>

<p>Alcuni livelli sono considerati <em><a
href="https://bugs.debian.org/release-critical/">release-critical</a></em>, vale
a dire che il problema avrà un certo impatto nell'inserire il pacchetto
nella versione stabile di Debian. Attualmente questi livelli sono
<strong>critical</strong>, <strong>grave</strong> e
<strong>serious</strong>. Per le regole complete che definiscono quali
problemi meritino questo tag si faccia riferimento 
all'<a href="https://release.debian.org/testing/rc_policy.txt">elenco dei
problemi release-critical per il prossimo rilascio</a>.</p>

<h2><a name="tags">Tag per le segnalazioni</a></h2>
 
<p>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.</p>

<p>I tag possono essere creati inserendo una linea <code>Tags</code> nello
pseudo-header quando la segnalazione è inviata (vedi le
<a href="Reporting#pseudoheader">istruzioni per inviare segnalazioni</a>),
o usando il codice comando <code>tags</code> con il
<a href="#requestserv">control request server</a>.
I tag vanno separati con una virgola e/o degli spazi.</p>

<p>I tag attuali sono: <bts_tags>. Di seguito alcune informazioni
dettagliate sui tag:</p>

<dl>

<dt><code>patch</code></dt>
  <dd>Una <i>patch</i> o altra semplice procedura che sistema il problema è
  presente nel log. Se la <i>patch</i> fornita non elimina in maniera completa
  il bug allora questo tag non dovrebbe essere utilizzato.</dd>

<dt><code>wontfix</code></dt>
  <dd>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.</dd>

<dt><code>moreinfo</code></dt>
  <dd>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 <q>non funziona</q>. Cosa non funziona?</dd>

<dt><code>unreproducible</code></dt>
  <dd>Questo bug non è riproducibile dal manutentore. È richiesta quindi
  l'assistenza di altre persone per la diagnosi del problema.</dd>

<dt><code>help</code></dt>
<dd>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 <code>newcomer</code>.</dd>

<dt><code>newcomer</code></dt>
<dd>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à.</dd>
 
<dt><code>pending</code></dt>
  <dd>Una soluzione per questo problema è stata trovata e un nuovo pacchetto
  verrà inviato al più presto.</dd>

<dt><code>fixed</code></dt>
  <dd>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".</dd>

<dt><code>security</code></dt>
  <dd>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".</dd>

<dt><code>upstream</code></dt>
  <dd>Questo bug riguarda la parte originaria del pacchetto.</dd>

<dt><code>confirmed</code></dt>
  <dd>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).</dd>

<dt><code>fixed-upstream</code></dt>
  <dd>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).

<dt><code>fixed-in-experimental</code></dt>
  <dd>Il bug è stato corretto nel pacchetto della distribuzione
  "experimental", ma non ancora in quella "unstable".</dd>

<dt><code>d-i</code></dt>
  <dd>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.</dd>

<dt><code>ipv6</code></dt>
  <dd>Questa segnalazione è relativa al supporto per Internet Protocol
  versione 6.</dd>

<dt><code>lfs</code></dt>
  <dd>Questa segnalazione è relativa al supporto per i file grandi
  (maggiori di 2 gigabyte).</dd>

<dt><code>l10n</code></dt>
  <dd>Questo bug è pertinente alla localizzazione del pacchetto.</dd>

<dt><code>a11y</code></dt>
  <dd>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.</dd>

<dt><code>ftbfs</code></dt>
  <dd>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).</dd>

<dt><bts_release_tags></dt>
  <dd>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.</dd>

<dt><bts_release_ignore_tags></dt>
  <dd>Questo è un bug release-critical ma può essere ignorato con lo scopo
  di arrivare al rilascio della distribuzione.
  <strong>Questo tag deve essere utilizzato solo dai manager dei rilasci;
  non usate questo tag senza il loro permesso esplicito.</strong></dd>

</dl>

<p>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 <strong>non è</strong> presente nelle distribuzioni per le quali
quel bug non ha il tag 'release'.</p>

<p>
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 "owner@bugs.debian.org">) oppure il
"release team" per un consulto.
</p>

<h2><a name="forward">Registrazione di segnalazione esterna a Debian</a></h2>

<p>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.</p>

<p>Assicurati che il campo <code>To</code> del tuo messaggio contenga solo
l'indirizzo dell'autore o degli autori del pacchetto e che il campo <code>Cc</code>
contenga sia l'indirizzo di chi ha fatto la segnalazione, sia
<var>nnn</var><code>-forwarded@bugs.debian.org</code>, sia
<VAR>nnn</VAR><CODE>@bugs.debian.org</CODE>.</p>

<p>Chiedi all'autore di mantenere il campo <code>Cc</code> con
<var>nnn</var><code>-forwarded@bugs.debian.org</code> 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 <VAR>nnn</VAR><CODE>@bugs.debian.org</CODE>.</p>

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

<p>Puoi modificare quest'ultima informazione spedendo un messaggio
a <a href="server-control"><code>control@bugs.debian.org</code></a>.</p>

<h2><a name="owner">Cambiare il proprietario</a></h2>

<p>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.</p>

<p>Il proprietario può essere impostato inserendo una linea
<code>Owner</code> nello pseudo-header della segnalazione (cfr:
<a href="Reporting#pseudoheader">come segnalare bug</a>), o
utilizzando i comandi <code>owner</code> e <code>noowner</code>
del <a href="#requestserv">control request server</a>.</p>

<h2><a name="maintincorrect">Manutentori di pacchetto elencati erroneamente</a></h2>

<p>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
<code>Maintainer</code> 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 <code>override-change@debian.org</code> per cambiare il file in
questione.</p>


<h2><a name="requestserv">Riapertura, diverso assegnamento
e gestione delle segnalazioni</a></h2>

<p>È 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 <code>control@bugs.debian.org</code>.</p>

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

<h2><a name="subscribe">Iscrizione ad un bug</a></h2>

<p>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 <a href="https://tracker.debian.org">Debian Package Tracker</a>.
Tutti i messaggi inviati a <var>nnn</var><code>@bugs.debian.org</code>
vengono spediti agli iscritti.</p>

<p>Per iscriversi ad un bug si deve inviare un email a
<var>nnn</var><code>-subscribe@bugs.debian.org</code>. 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.</p>

<p>È anche possibile annullare l'iscrizione ad un bug. Lo si fa
inviando un email a <var>nnn</var><code>-unsubscribe@bugs.debian.org</code>.
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.</p>

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

<h2><a name="subjectscan">Feature più o meno vecchie riguardo all'analisi dell'oggetto</a></h2>

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

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

<p>I messaggi che arrivano a <code>forwarded</code> e
<code>done</code> &mdash; vale a dire senza alcun numero di segnalazione
nell'indirizzo &mdash; e senza numero di segnalazione nell'oggetto saranno
mantenuti solo per alcune settimane.</p>


<h2><a name="x-debian-pr">Caratteristica vecchia: <code>X-Debian-PR: quiet</code></a></h2>

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

<p>Questa linea è ormai ignorata. Per ottenere lo stesso scopo il
messaggio va indirizzato a <code>quiet</code> o
<var>nnn</var><code>-quiet</code> (o <code>maintonly</code> o
<var>nnn</var><code>-maintonly</code>).</p>

<hr />

#use "otherpages.inc"

#use "$(ENGLISHDIR)/Bugs/footer.inc"