Differences between revisions 2 and 3
⇤ ← Revision 2 as of 2011-01-08 13:54:12 →
Size: 13129
Editor: ?ErmenegildoFiorito
Comment:
← Revision 3 as of 2011-01-09 21:57:50 → ⇥
Size: 11996
Editor: ?ErmenegildoFiorito
Comment: throw in the towel
Deletions are marked like this. Additions are marked like this.
Line 113: Line 113:
Il comando '''{{{tag}}}''' ti aiuta a classificare i bug. Arrualmente segnalando bug puoi aggiungere anche ''Tags: '' agli pseudo header e specificare i tags per una segnalazione. Il comando '''{{{tag}}}''' ti aiuta a classificare i bug. Arrualmente segnalando i bug puoi aggiungere anche ''Tags: '' agli pseudo header e specificare i tags per una segnalazione.
Line 134: Line 134:
And this is also the place where I come back to the special bug group of '''release-critical bugs''' that I mentioned earlier. Because bug reports can get archived after 28 days if they fulfil some criteria: usually bugs have to get fixed both in unstable and in testing to get archived. Ed è anche il posto dove trovare il gruppo speciale '''release-critical bugs''' di cui ho parlato prima. Perchè le segnalazioni vengono archiviate dopo 28 giorni sempre che soddisfino determinati criteri: di norma quelli che vengono corretti sia in unstable sia in testing vanno in archivio.
Line 136: Line 136:
Of course only if they affect both releases - a bug report that affects only unstable but not testing (because of the found version) can get archived right ahead - if it's built on all architectures. Naturalmente solo se questi affliggono entrambe le release -una segnalazione può coprire anche solo unstable -se è stato creato un pacchetto per tutte le architetture.
Line 138: Line 138:
So, the affected distributions is one criterion, the affected architectures the other. If both criteria are solved and fixed, the timer starts. Quindi la distribuzione colpita è un criterio, per le architetture è un altro. Se entrambi i criteri solo risolti, il timer comincia.
Line 140: Line 140:
Bug reports can get closed in several ways. The most common is through a package upload that contains a ''closes: #12345'' in the ''changelog''. When the package is accepted into the archive this triggers a mail to ''12345-done@bugs.debian.org'' with ''Version: 1.2.3'' in the first line of the mail. This can obviously also be done manually, so if one does send a mail to ''-done@bugs'' with a ''Version:'' header that also claims the bug report to be fixed in that version. Le segnalazioni posso essere chiuse i molti modi. Quello più comune è un pacchetto caricato che contiene, ad esempio, ''closes: #12345'' nel ''changelog''. Quando il pacchetto è accettato nell'archivio viene mandata una mail a ''12345-done@bugs.debian.org'' con ''Version: 1.2.3'' nella prima linea dell'mail. Questo ovviamente può essere fatto a mano, si può mandare una mail a ''-done@bugs'' con l'header ''Version:'' che informa della chiusura del bug in quella versione.
Line 142: Line 142:
If the bug report is a non-issue (like, a false report) then the ''Version:'' line should be NOT added to the mail. Se la segnalazione è un "non problema" (come, una falsa segnalazione), l'header ''Version:'' non dovrà essere aggiunto alla mail.
Line 144: Line 144:
This difference is needed for the BTS to be able to distinguish bugs fixed in a specific version and bugs that aren't really bugs.

The later will start right ahead with the 28 day period. The former will only start when the package in that version is in sync in unstable on all architectures and also in testing (if the bug affects testing).

I still haven't touched the release critical bug reports that are thrown around anywhere.

'''release-critical bug reports''' will ALSO have to be fixed for stable to start their archival process. So even when a release critical bug report got closed in unstable, did move over to testing and is in sync on all architectures, it will NOT get archived as long as the version tracking still thinks it affects stable.

The BTS web interface has a very helpful feature for all of this: '''The version graph'''. You might have noticed it already in some individual bug reports, it's in the upper right-hand corner. It consists of several boxes: red round ones and green square ones. The green ones are those of fixed versions, the red ones are those versions affected.

Like mentioned earlier, feel free to click around - this includes clicking on the version graphs. This will immensely enhance readability of them. ;)		 Questa differenza è richiesta perchè il BTS deve essere in grado di distinguere i bug corretti di una specifica versione che non sono bug reali.

Translation(s): it

Contents

  1. Come usare il sistema di Bug Tracking
  2. Requisiti
  3. Interrogare le segnalazioni sui bug: L'interfaccia web di BTS
  4. Segnalare i bug: reportbug
  5. Ottimizzare le segnalazioni dei bug: control@bugs.debian.org
  6. Tracciamento di versione

Come usare il sistema di Bug Tracking

Seminario online tenuto da Gerfried Fuchs, 09-Dec-2010

Questa è una guida all'uso del Sistema di Bug Tracking (BTS).

L'acronimo BTS sta per Bug Tracking System ed è dove debian conserva e traccia i bug riportati ( incluse le liste sulle feature desiderate(wishlist), che non sono veri e propri bug). È principalmente un sistema di posta elettronica -attualmente infatti migliorarlo e ritoccarlo può essere fatto solamente mandando e-mail al sistema.

Requisiti

Requisiti tecnici:

Interrogare le segnalazioni sui bug: L'interfaccia web di BTS

L' Interfaccia web di BTS può essere trovata all'indirizzo http://bugs.debian.org/. Attraverso questo portale puoi interrogare tutte le segnalazioni sui bug piuttosto rapidamente ( a meno che il server non sia troppo carico ) ed è anche estremamente conveniente.

Se vai su http://bugs.debian.org/ verrai reindirizzato ad una pagina che offre un form dal qualche puoi eseguire delle ricerche -ma la parte più utile sono i vari reindirizzamenti che offre.

  • Se tu sei un maintainer di pacchetti, puoi andare all'indirizzo http://bugs.debian.org/tuo@indiriz.zo e vedere le segnalazioni ( lasciate in sospeso ) dei bug di tutti i tuoi pacchetti mantenuti, con l'indirizzo email che usi.

  • Se tu sei dall'altra parte segnalatore di rapporti ( e spero che tu non abbandoni i bug che trovi, dopo un po' di tempo, nel caso in cui non vengano corretti subito ) vai a http://bugs.debian.org/from:tuo@indiriz.zo per vedere tutte le tue segnalazioni di bug che non sono stati corretti.

  • Se vuoi segnalare un nuovo bug devi controllare prima se il bug è già stato riportato. Per fare questo la pagina http://bugs.debian.org/packagename offre una panoramica per tutte le segnalazioni sui bug per il pacchetto dato.

Ricordati però che questo tiene conto solo delle segnalazioni per i pacchetti binari.

  • Se vuoi vedere una segnalazione combinata per tutti i pacchetti binari creati dallo stesso pacchetto sorgente, come ad esempio openoffice.org devi andare invece all'indirizzo http://bugs.debian.org/src:openoffice.org (nota il prefisso :src).

* se tu hai il numero della segnalazione di un bugpuoi andare direttamente alla segnalazione dello stesso aggiungendo il numero all'URL, come ad esempio http://bugs.debian.org/12345

La pagina panoramica ti permette di avere il ragruppamento delle segnalazioni dei bug con i link all'interno della pagina, e sotto, un altro form che ti aiuta a cambiare la vista per quanto riguarda diversi aspetti.

In più, tieni a mente che sulla pagina panoramica ci sono dei carratteri piuttosto cripticidopo la breve descrizione. è sufficiente posizionare il mouse su di loro per ottenere un suggerimento, e si può cliccare su di loro per far aprire un pop-up contente ulteriori informazioni sul bug in questione.

Questo è il riassunto breve sull'interfaccia web. Come ho detto, è solo una interfaccia di query. Quindi sentitevi liberi di cliccare in giro, esplorare completamente il sito - non può accadere nulla di male.

Segnalare i bug: reportbug

Per la segnalazione dei bug hai bisogno di un cliente di posta elettronica, più convenientemente, usare lo strumento reportbug. reportbug è principalmente un programma testuale ( ma ci sono due interfacce: urwid e altre scritte in GTK+) c'è anche reportbug-ng che è un'interfaccia grafica che mira a fare lo stesso lavoro, ma è comunque uno strumento differente.

Entrambi hanno bisogno di un MTA in locale (Mail Transport Agent) come postfix, exim, o ssmtp. Non voglio entrare nei dettagli su come devono essere configurati, in realtà è molto utile per alcuni averne uno localmente in modo da poter scrivere mail sul proprio computer portatile quando sono offline e inviarle quando tornano di nuovo online.

Anche se quando non si dispone di un MTA locale, la segnalazione dei bug, è ancoramolto utile. Perchè ha l'opzione --template. Questo vi aiuterà a produrre informazioni per la segnalazione di bug che il manutentore del pacchetto avrebbe altrimenti richiesta in ogni caso, come le informazioni sulle dipendenze o simili.

Basta lanciare nel terminale: 

reportbug --template package

con il nome del pacchetti che hai installato. Non preoccuparti, non fa nulla di pericoloso, mostra solo alcune righe di testo :)

Ci sono diverse cose importanti che ti daranno un'idea su cosa fare, come a chi inviare le e-mail : 

To: Debian Bug Tracking System <submit@bugs.debian.org>

Il submit@bugs è dove le nuove segnalazioni vengono mandate. Ovviamente nella tua segnalazione dei inserire un utile e descrittivo titolo che dia al package manager una prima idea su quale sia il problema.

Poi c'è un altro blocco che comincia con Package:, ha Version: e la linea Severity: :

  • Le linee Package: e Version: devono essere le prime linee della tua segnalazione, all'interno del corpo dell'email dove solitamente scrivi Caro amico,.

  • La linea Severity: è opzionale, puoi lasciare vuota se si trotta di una "normale" segnalazione

    severity può avere diversi livelli di importanza, da grave, critical, serious, fino a important e da normal a minor e whishlist.

I primi tre (grave, critical and serious) sono considerati versione critica e definiscono un speciale gruppo di segnalazioni. Se sei in dubbio, non usarli almeno che non tu non sia sicuro di cosa significhino, alcune persone potrebbero reagire nervosamente se vengono utilizzate segnalazioni che alla fine non sono tanto gravi. Tornerò sull'argomento del significato delle versioni critiche più tardi.

whishlist è la gravità per il miglioramento che vorresti vedere in un pacchetto. Alcuni maintainer di pacchetti potrebbero suggerirti di segnalarli direttamente all'upstream - anche se personalmente ritengo che i maintainer di pacchetti debbano fungere dal tramite tra i nostri utenti e gli sviluppatori upstream.

In fine ricordati, prova ad essere descrittivo non solo nel titolo del bug, ma anche nel corpo della segnalazione, e sarebbe fantastico anche se tu segnalassi il modo per riprodurre il tuo bug.

Per la segnalazione dei bug, c'è altra documentazione a questo indirizzo http://www.debian.org/Bugs/Reporting.

Ottimizzare le segnalazioni dei bug: control@bugs.debian.org

Per ottimizzare le segnalazioni dei bug, c'è l'indirizzo email control@bugs.debian.org. L'intero sistema di bug tracking è aperto a chiunque, come è questo indirizzo mail. Questo significa che qualsiasi persone è tecnicamente abile per ottimizzare qualsiasi segnalazione di bug. L'indirizzo di controllo è dove inizia il divertimento. Funziona come l'indirizzo per la segnalazione nelle prime linee.

La documentazione per questo indirizzo puoi trovarla a: http://www.debian.org/Bugs/server-control

Normalmente la sintassi è: 

 command bugnumber arguments

Il numero di argomenti varia a seconda dei comandi:

Quindi con retitle: 

retitle 12345 new-title

imposti il titolo della segnalazione da 12345 a new-title.

Non preoccuparti, non può essere fatto per questo numero di segnalazione, il bug è già stato archiviato. Puoi ottimizzare solo le segnalazioni non ancora archiviate.

Un comando solitamente usato è reassign per asseggnare un bug ad un altro pacchetto. Questo comando prende il secondo argomento dopo il nome del pacchetto: Il numero di versione. Se tu sai quale è la versione dell'altro pacchetto affetto dal bug è davvero utili aggiungere la versione così il tracciamento continuerà il suo lavoro. Spiegerò il tracciamento di versione dopo, I will explain version tracking a bit later, ho fatto alcuni esempi per semplificare la sua comprensione. :)

Il comando tag ti aiuta a classificare i bug. Arrualmente segnalando i bug puoi aggiungere anche Tags: agli pseudo header e specificare i tags per una segnalazione.

Molti tag regolarmenti usati sono:

  • patch: quando aggiungi una patch con la tua mail

  • moreinfo e unreproducible: quando i maintainer hanno problemi a capire l'origine del problema

  • security: quando il bug è un problema di sicurezza.

La lista dei tag può essere consultata su: http://www.debian.org/Bugs/Developer#tags.

Se vuoi iscriverti ad una specifica segnalazione, manda una mail a bugnumber-subscribe@bugs.debian.org. Riceverai una mail che richiede la conferma della iscrizione, da questo punto in poi riceverai tutte le mail mandate a quella segnalazione. Puoi anche iscriverti alle segnalazioni di uno specifico pacchetto attraverso il PTS (Package Tracking System) a http://packages.qa.debian.org/NOMEPACCHETTO. In basso a sinistra troverai il form di iscrizione.

Ma se una persona manda una mail sia a control@bugs che a bugnumber@bugs naturalmente non vuoi confondere il control parser con il testo che hai aggiunto al package maintainer. Per questo motivo c'è un comando speciale thanks che ti permette di essere avvertito dopo comandi del controller. Questo dice al parser di fermare il parsing dell'email da quel punto in poi.

Prendi nota che le email mandate a bugnumber@bugs arrivano al maintainer del pacchetto (e le persone sottoscritte ad esso). Queste email NON vengono mandate alle persone che segnalano i bug! Questo è anche qualcosa che è in discussione da cambiare - per il momento, c'è bisogno o di scovare il mittente della segnalazione del bug e aggiungerlo esplicitamente alle copie, o, per praticità, utilizzare un altro indirizzo di posta elettronica:bugnumber-submitter@bugs.debian.org.

Tracciamento di versione

Cos'è il tracciamento di versione? BTS tiene traccia di quale versione di una bug è stata chiusa, quali altre release colpisce, ecc. Per questo lo pseudo-header Version: è molti importante nella segnalazione di un bug. Anche se il BTS potrebbe invece pensare che colpisce solo una determinata versione del pacchetto.

Ed è anche il posto dove trovare il gruppo speciale release-critical bugs di cui ho parlato prima. Perchè le segnalazioni vengono archiviate dopo 28 giorni sempre che soddisfino determinati criteri: di norma quelli che vengono corretti sia in unstable sia in testing vanno in archivio.

Naturalmente solo se questi affliggono entrambe le release -una segnalazione può coprire anche solo unstable -se è stato creato un pacchetto per tutte le architetture.

Quindi la distribuzione colpita è un criterio, per le architetture è un altro. Se entrambi i criteri solo risolti, il timer comincia.

Le segnalazioni posso essere chiuse i molti modi. Quello più comune è un pacchetto caricato che contiene, ad esempio, closes: #12345 nel changelog. Quando il pacchetto è accettato nell'archivio viene mandata una mail a 12345-done@bugs.debian.org con Version: 1.2.3 nella prima linea dell'mail. Questo ovviamente può essere fatto a mano, si può mandare una mail a -done@bugs con l'header Version: che informa della chiusura del bug in quella versione.

Se la segnalazione è un "non problema" (come, una falsa segnalazione), l'header Version: non dovrà essere aggiunto alla mail.

Questa differenza è richiesta perchè il BTS deve essere in grado di distinguere i bug corretti di una specifica versione che non sono bug reali.