path: root/italian/Bugs/server-control.wml

#use wml::debian::template title="Debian BTS — server di controllo" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
#use wml::debian::translation-check translation="eeaeaa4686ab3760dcfb69cfc7763efb9f48537b" maintainer="Francesca Ciceri"

<h1>Introduzione al server di posta di controllo e gestione bug</h1>

<p>
Così come <code>request@bugs.debian.org</code> permette di
<a href="server-request">ottenere informazioni su segnalazioni e
documentazione via e-mail</a>, <code>control@bugs.debian.org</code>
permette di manipolare in vari modi i rapporti sui bug.
</p>

<p>
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
<code>nnn@bugs.debian.org</code>. Per farlo è necessario iniziare l'e-mail con i
comandi preceduti da <code>Control: </code>. Un metodo alternativo è quello di
inviare una copia dell'e-mail a <code>control@bugs.debian.org</code> e scrivere i
comandi nell'e-mail con l'aggiunta del comando finale <code>thanks</code>.
</p>

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

<p>
Leggi la 
<a href="server-request#introduction">introduzione al server di richiesta</a>
disponibile sul World Wide Web, 
nel file
<code>bug-log-mailserver.txt</code>, o invia
<code>help</code> 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.
</p>

<p>
La <a href="server-refcard">scheda di riferimento</a>
per i server di posta è disponibile via WWW, in
<code>bug-mailserver-refcard.txt</code> o inviando un'e-mail e usando il
comando <code>refcard</code>.
</p>

<h1>Comandi disponibili sul server di posta di controllo</h1>

  <table style="margin-left:auto;margin-right:auto">
    <tr>
    <td align="center">Generale</td>
    <td align="center">Versioni</td>
    <td align="center">Duplicati</td>
    <td align="center">Altro</td>
    </tr>
    <tr>
      <!-- General -->
      <td valign="top">
        <ul class="nodecoration">
          <li><a href="#reassign">reassign</a></li>
          <li><a href="#severity">severity</a></li>
          <li><a href="#tag">tags</a></li>
          <li><a href="#retitle">retitle</a></li>
          <li><a href="#submitter">submitter</a></li>
	  <li><a href="#affects">affects</a></li>
	  <li><a href="#summary">summary</a></li>
	  <li><a href="#outlook">outlook</a></li>
        </ul>
      </td>
      <!-- Versioning -->
      <td valign="top">
        <ul class="nodecoration">
          <li><a href="#found">found</a> | <a href="#notfound">notfound</a></li>
          <li><a href="#fixed">fixed</a> | <a href="#notfixed">notfixed</a></li>
          <li><a href="#reopen">reopen</a></li>
          <!-- <dt>(close)</dt> Deprecated -->
        </ul>
      </td>
      <!-- Duplicates -->
      <td valign="top">
        <ul class="nodecoration">
          <li><a href="#merge">merge</a> | <a href="#unmerge">unmerge</a></li>
          <li><a href="#forcemerge">forcemerge</a></li>
          <li><a href="#clone">clone</a></li>
        </ul>
      </td>
      <!-- Misc. -->
      <td valign="top">
        <ul class="nodecoration">
          <li><a href="#thanks">thanks</a></li>
          <li><a href="#comment">#</a></li>
          <li><a href="#forwarded">forwarded</a> | <a href="#notforwarded">notforwarded</a></li>
          <li><a href="#owner">owner</a> | <a href="#noowner">noowner</a></li>
          <li><a href="#block">block</a> | <a href="#unblock">unblock</a></li>
          <li><a href="#archive">archive</a> | <a href="#unarchive">unarchive</a></li>
          <li><a href="server-request#user">user</a> |
            <a href="server-request#usertag">usertag</a> |
            <a href="server-request#usercategory">usercategory</a></li>
        </ul>
      </td>
    </tr>
  </table>

<dl>
  <dt><a name="reassign"><code>reassign</code> <var>bugnumber</var> <var>pacchetto</var>
      [ <var>versione</var> ]</a></dt>
  <dd>
    <p>
    Registra che il bug #<var>bugnumber</var> è un bug in <var>pacchetto</var>.
    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).
    </p>

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

    <p>
      Si può assegnare una segnalazione a due pacchetti in un solo
      comando separando i nomi dei pacchetti con una virgola.
      <em>Ciononostante</em>, questo va fatto solo se il problema può
      essere risolto da una modifica in <em>uno qualsiasi</em> dei due pacchetti.
      In tutti gli
      altri casi si deve fare il <a href="#clone">clone</a> della
      segnalazione e assegnarne la copia all'altro pacchetto.
    </p>
  </dd>

  <dt><a name="reopen"><code>reopen</code> <var>bugnumber</var>
      [ <var>originator-address</var> | <code>=</code> | <code>!</code> ]</a></dt>
  <dd>
    <p>
    Riapre #<var>bugnumber</var> e cancella tutte le versioni in cui è
	risolto se è stato chiuso.
    </p>

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

    <p>
    Se fornisci un <var>originator-address</var> 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
    <code>!</code> o specificare il tuo indirizzo e-mail.
    </p>

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

    <p>
    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 <code>submitter</code>; si noti che
    questo avviserà il proprietario del precedente indirizzo di origine
    del bug del cambio.
    </p>

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

  <dt><a name="found"><code>found</code> <var>bugnumber</var>
      [ <var>versione</var> ]</a></dt>
  <dd>
    <p>
    Segna che il bug numero <var>bugnumber</var> è stato riscontrato
    in una certa versione del pacchetto al quale è assegnato.
    <var>version</var> può essere una versione nella forma
    <var>nomepacchettosorgente</var>.
    </p>

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

    <p>
    Se non viene specificata la <var>versione</var> allora l'elenco delle
    versioni corrette viene azzerato. Questo è lo stesso comportamento
    che si ha con <code>reopen</code>.
    <var>version</var> può essere una versione nella forma
    <var>nomepacchettosorgente</var>.
    </p>

    <p>
    Questo comando marcherà la segnalazione come non chiusa se
    non viene specificata alcuna versione; oppure se la <var>versione</var>
    marcata è la stessa o superiore della più alta <var>versione</var> 
    che è stata marcata fixed per ultima. (Se si è certi 
    di non voler chiudere la segnalazione, utilizzare <code>reopen</code> 
    con <code>found</code>.)
    </p>

    <p>
    Questo comando è stato introdotto in sostituzione
    di <code>reopen</code> perché non era possibile modificare
    quest'ultimo aggiungendogli il parametro <var>versione</var>
    senza ambiguità.
    </p>
  </dd>

  <dt><a name="notfound"><code>notfound</code> <var>bugnumber</var>
      <var>versione</var></a></dt>
  <dd>
    <p>
    Cancella la registrazione che il bug numero <var>bugnumber</var> sia
    presente nella versione <var>versione</var> del pacchetto al quale è
    assegnato.
    <var>version</var> può essere una versione nella forma
    <var>nomepacchettosorgente</var>.
    </p>

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

  <dt><a name="fixed"><code>fixed</code> <var>bugnumber</var>
      <var>versione</var></a></dt>
  <dd>
    <p>
    Indica che il bug numero <var>bugnumber</var> è stato
    corretto nella <var>versione</var> del pacchetto al quale è
    assegnato.
    <var>version</var> può essere una versione nella forma
    <var>nomepacchettosorgente</var>.
    </p>

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

  <dt><a name="notfixed"><code>notfixed</code> <var>bugnumber</var>
      <var>versione</var></a></dt>
  <dd>
    <p>
    Cancella l'indicazione che il bug numero <var>bugnumber</var> sia
    stato risolto nella specifica <var>versione</var>.
    <var>version</var> può essere una versione nella forma
    <var>nomepacchettosorgente</var>.
    </p>

    <p>
    Questo comando è equivalente al comando <code>found</code> seguito
    dal comando <code>notfound</code> (il <code>found</code> rimuove il
    <code>fixed</code> in una versione specifica, mentre il <code>notfound</code>
    rimuove il <code>found</code>) 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 <code>found</code> invece che
    <code>notfixed</code>.
    </p>
  </dd>

  <dt><a name="submitter"><code>submitter</code> <var>bugnumber</var>
      <var>indirizzo-di-originatore</var> | <code>!</code></a></dt>
  <dd>
    <p>
    Cambia l'originatore del #<var>bugnumber</var> in
    <var>indirizzo-di-originatore</var>.
    </p>

    <p>
    Se si voglia diventare nuovo originatore di una segnalazione si può
    utilizzare l'abbreviazione <code>!</code> o specificare il proprio
    indirizzo e-mail.
    </p>

    <p>
    Nonostante il comando <code>reopen</code> cambi l'originatore delle
    segnalazioni unite a quella riaperta, <code>submitter</code> non 
    influisce sulle segnalazioni unite.
    </p>
  </dd>

  <dt><a name="forwarded"><code>forwarded</code> <var>bugnumber</var>
      <var>indirizzo</var></a></dt>
  <dd>
    <p>
    Notifica che <var>bugnumber</var> è stato reinviato per conoscenza
    al upstream maintainer
    presso <var>indirizzo</var>. 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. <var>indirizzo</var>
    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.
    </p>

    <p>
    Esempio d'utilizzo:
    </p>

    <pre>
      forwarded 12345 http://bugz.illa.foo/cgi/54321
    </pre>
  </dd>

  <dt><a name="notforwarded"><code>notforwarded</code>
      <var>bugnumber</var></a></dt>
  <dd>
    <p>
    Dimentica qualsiasi idea che <var>bugnumber</var> 
    sia stato inviato per conoscenza a un qualche
    upstream maintainer. Se il bug non era stato registrato come inviato
    per conoscenza, non farà nulla.
    </p>
  </dd>

  <dt><a name="retitle"><code>retitle</code> <var>bugnumber</var>
      <var>nuovo-titolo</var></a></dt>
  <dd>
    <p>
    Modifica il titolo di un rapporto di bug in quello specificato
    (il default è l'intestazione <code>Subject</code>) dal rapporto originale.
    Verrà cambiato anche il titolo di tutti i rapporti di bug con i quali
    questo è collegato.
    </p>

  </dd>

  <dt><a name="severity"><code>severity</code> <var>bugnumber</var>
      <var>gravità</var></a></dt>
  <dd>
    <p>Imposta il livello di gravità del rapporto bug #<var>bugnumber</var> a
    <var>gravità</var>. Nessuna notifica viene inviata all'utente che ha riportato
    il bug.
    </p>

    <p>
    Le gravità sono <bts_severities>.
    </p>

    <p>
    Per <a href="Developer#severities">il loro significato</a> 
    consulta la documentazione generale dello sviluppatore
    per il sistema dei bug.
    </p>
  </dd>

  <dt><a name="affects"><code>affects</code> <var>bugnumber</var>
      [ <code>+</code> | <code>-</code> | <code>=</code>
      ] <var>package</var> [ <var>package</var> ... ]</a></dt>
  <dd>
    <p>
      Indica che un bug colpisce anche un altro pacchetto. Nel caso in cui
      <var>bugnumber</var> causi una rottura in <var>package</var> 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 <var>package</var>. Questo dovrebbe accadere
      laddove il bug è abbastanza grave da causare segnalazioni multiple dagli
      utenti che lo assegnano al pacchetto sbagliato. <code>=</code>
      definisce come affetti dal bug i pacchetti
      indicati, ed è l'azione predefinita se non vengono specificati pacchetti;
      <code>-</code> rimuove i pacchetti indicati dalla lista di quelli
      affetti dal bug; <code>+</code> aggiunge i pacchetti indicati alla
      lista di quelli affetti dal bug ed è l'opzione predefinita nel caso
      in cui siano specificati dei pacchetti.
    </p>
  </dd>

  <dt><a name="summary"><code>summary</code> <var>bugnumber</var>
  [<var>message number</var> | <var>summary text</var>]</a></dt>
  <dd>
    <p>
      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.
    </p>
    <p>
      Se <var>message number</var> non è fornito, il sommario viene
      cancellato. <var>message number</var> è il numero del messaggio come
      elencato nell'output dello script cgi di bugreport; se un viene
      fornito un <var>message number</var> di 0, viene usato il messaggio
      presente (ovvero, il messaggio che è stato inviato a
      control@bugs.debian.org e che contiene il comando di controllo
      summary).
    </p>
    <p>
      Se <var>message number</var> non è un numero né una stringa vuota
      il sistema lo interpreterà come il testo con il quale configurare
      il sommario.
    </p>
  </dd>

  <dt><a name="outlook"><code>outlook</code> <var>bugnumber</var>
      [<var>message number</var> | <var>outlook text</var>]</a></dt>
  <dd>
    <p>
      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).
    </p>
    <p>
      Quando <var>message number</var> non è indicato, lo stato di
      avanzamento del bug viene ripulito.
      <var>message number</var> è il numero del messaggio, così come
      riportato nell'output dello script cgi della segnalazione del bug;
      se viene fornito un <var>message number</var> uguale a 0, 
      si continuerà ad utilizzate il messaggio attuale 
      (ovvero il messaggio che è stato inviato all'indirizzo
      control@bugs.debian.org contenente il comando outlook).
    </p>
    <p>
      Se <var>message number</var> non è un numero né una stringa vuota,
      il sistema lo interpreterà come il testo con il quale configurare
      lo stato di avanzamento del bug.
    </p>

  </dd>

  <dt><a name="clone"><code>clone</code> <var>bugnumber</var>
      <var>new ID</var> [ <var>new IDs</var> ]</a></dt>
  <dd>
    <p>
    Il comando di controllo clone permette di duplicare una segnalazione.
    È utile quando una singola segnalazione indica vari bug. 
    <q><var>New IDs</var></q> 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.
    </p>

    <p>
    Esempio di utilizzo:
    </p>

    <pre>
        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
    </pre>
  </dd>

  <dt><a name="merge"><code>merge</code> <var>bugnumber</var>
      <var>bugnumber</var> ...</a></dt>
  <dd>
    <p>
    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.
    </p>

    <p>
    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 
    <code>reassign</code>, <code>reopen</code> e così via 
    per essere sicuro che lo siano prima di usare <code>merge</code>.
    Non è necessario che i titoli corrispondano e non saranno
    modificati dal merge. Neanche i tag devono corrispondere e, anzi,
    verranno uniti.
    </p>

    <p>
    Se uno dei bug elencati in un comando <code>merge</code>
    è 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.
    </p>

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

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

  <dt><a name="forcemerge"><code>forcemerge</code> <var>bugnumber</var>
      <var>bugnumber</var> ...</a></dt>
  <dd>
    <p>
    Forza il collegamento tra due o più segnalazioni. Le caratteristiche del
    primo bug elencato (quelle che devono corrispondere per il
    <code>merge</code>) 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.
    </p>
  
    <p>Nota che questo rende possibile la chiusura di una segnalazione tramite
    il <code>merge</code>; sei quindi responsabile della notifica al segnalatore
    con un messaggio che notifichi la chiusura della segnalazione.
    </p>
  </dd>

  <dt><a name="unmerge"><code>unmerge</code> <var>bugnumber</var></a></dt>
  <dd>
    <p>
    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.
    </p>

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

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

  <dt><a name="tags"><!-- match tags too --></a><a name="tag"><code>tags</code> <var>bugnumber</var> [ <code>+</code>
      | <code>-</code> | <code>=</code> ] <var>tag</var> [
      <var>tag</var> ... ][ <code>+</code> | <code>-</code> | <code>=</code> <var>tag</var> ... ] ]</a></dt>
  <dd>
    <p>
    Imposta un particolare tag per il rapporto su bug #<var>bugnumber</var> al valore
    <var>tag</var>. Nessuna notifica è inviata all'utente che ha riportato
    il bug. <code>+</code> significa aggiungi ciascun <var>tag</var> successivo, 
    <code>-</code> significa sottrai ciascun <var>tag</var> successivo e
    <code>=</code> significa imposta i tag successivi all'elenco fornito. I
    <code>+</code>, <code>-</code>, <code>=</code> interposti cambiano
    l'azione per il tag successivo. L'azione predefinita è aggiungi.
    </p>

    <p>
    Esempio d'uso:
    </p>

    <pre>
        \# 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
    </pre>

    <p>
    I tag attualmente disponibili includono <bts_tags>.
    </p>

    <p>
    Per <a href="Developer#tags">i loro significati</a> consulta 
    la documentazione generale dello sviluppatore per il sistema dei bug.
    </p>
  </dd>

  <dt><a name="block"><code>block</code> <var>bugnumber</var> <code>by</code>
      <var>bug</var> ...</a></dt>
  <dd>
    <p>
    Segnala che la soluzione di questo bug è bloccata da un altro.
    </p>
  </dd>

  <dt><a name="unblock"><code>unblock</code> <var>bugnumber</var> <code>by</code>
      <var>bug</var> ...</a></dt>

  <dd>
    <p>
    Segnala che la soluzione di questo bug non è più
    bloccata da un altro.
    </p>
  </dd>

  <dt><a name="close"><code>close</code> <var>bugnumber</var> [ <var>fixed-version</var> ]
      (sconsigliato)</a></dt>
  <dd>
    <p>
    Chiude il rapporto sul bug #<var>bugnumber</var>.
    </p>

    <p>
    Una notifica viene inviata all'utente che ha riportato il bug,
    ma (in contrasto all'invio di un'e-mail a <var>bugnumber</var><code>-done@bugs.debian.org</code>)
    il testo dell'e-mail che ha causato la chiusura del bug <strong>non</strong> è
    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 <a href="Developer#closing">come
    chiudere una segnalazione correttamente</a>.
    </p>

    <p>
    Se si fornisce una versione in <var>fixed-version</var>, il sistema di
    tracciamento noterà che il bug è stato corretto in quella
    versione.
    </p>
  </dd>

  <dt><a name="package"><code>package</code> [ <var>nomepacchetto</var> ... ]</a></dt>
  <dd>
    <p>
    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.
    </p>

    <pre>
        package foo
        reassign 123456 bar 1.0-1

        package bar
        retitle 123456 bar: bar sucks
        severity 123456 normal

        package
        severity 234567 wishlist
    </pre>
  </dd>

  <dt><a name="owner"><code>owner</code> <var>numerobug</var>
      <var>indirizzo</var> | <code>!</code></a></dt>
  <dd>
    <p>
    Imposta <var>indirizzo</var> come "proprietario" del #<var>numerobug</var>.
    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.
    </p>

    <p>
    Se si vuole diventare il proprietario del bug, si può usare il
    <code>!</code> come scorciatoia o specificare il proprio indirizzo
    e-mail.
    </p>
  </dd>

  <dt><a name="noowner"><code>noowner</code> <var>numerobug</var></a></dt>
  <dd>
    <p>
    Elimina tutte le tracce di altri proprietari del bug al di fuori
    del manutentore ufficiale. Se non ci sono proprietari gi&agrave;
    memorizzati allora nulla cambia.
    </p>
  </dd>

  <dt><a name="archive"><code>archive</code> <var>numerobug</var></a></dt>
  <dd>
    <p>
    Archivia una segnalazione che era stata già archiviata
    in passato a condizione che abbia tutti i requisiti necessari,
    a parte quello del tempo.
    </p>
  </dd>

  <dt><a name="unarchive"><code>unarchive</code> <var>numerobug</var></a></dt>
  <dd>
    <p>
    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 <code>unarchive</code> per
    effettuare modifiche banali ai bug archiviati, come ad esempio cambiare
    l'originatore del bug; lo scopo principale di <code>unarchive</code> è di
    permettere la riapertura di bug che sono stati archiviati senza dover
    chiedere l'intervento degli amministratori di BTS.
    </p>
  </dd>

  <dt><a name="comment"><code>#</code>...</a></dt>
  <dd>
    <p>
    Commento di una linea. Il <code>#</code> 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.
    </p>
  </dd>

  <dt><a name="thanks"><code>quit</code></a></dt>
  <dt><code>stop</code></dt>
  <dt><code>thank</code>...</dt>
  <dt><code>thanks</code>...</dt>
  <dt><code>thankyou</code>...</dt>
  <dt><code>thank you</code>...</dt>
  <dt><code>--</code>...</dt>
  <dd>
    <p>
    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.
    </p>
  </dd>
</dl>

<hr />

#use "otherpages.inc"

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