Differences between revisions 1 and 2
Revision 1 as of 2011-01-08 00:40:53
Size: 3339
Editor: ?ErmenegildoFiorito
Comment: draft 0
Revision 2 as of 2011-01-08 13:54:12
Size: 13129
Editor: ?ErmenegildoFiorito
Comment:
Deletions are marked like this. Additions are marked like this.
Line 40: Line 40:
In più, tieni a mente che sulla pagina panoramica ci sono dei ''carratteri piuttosto critici''dopo la breve descrizione. You can hover with your mouse over them to get a tool tip, and you can click on them to receive a pop-up with some further information about the bug report at hand. In più, tieni a mente che sulla pagina panoramica ci sono dei ''carratteri piuttosto criptici''dopo 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.
Line 42: Line 42:
This is the short abstract about the web interface. Again, it's only a query interface. So feel free to click around, dig around - nothing bad can happen. 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 DebianPkg:reportbug. DebianPkg:reportbug è principalmente un programma testuale ( ma ci sono due interfacce: urwid e altre scritte in GTK+) c'è anche DebianPkg: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 DebianPkg:postfix, DebianPkg:exim, o DebianPkg: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, è ancora''molto 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 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.

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.

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.

So, the affected distributions is one criterion, the affected architectures the other. If both criteria are solved and fixed, the timer starts.

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.

If the bug report is a non-issue (like, a false report) then the ''Version:'' line should be NOT added to the mail.

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. ;)

Translation(s): it



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

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.

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.

So, the affected distributions is one criterion, the affected architectures the other. If both criteria are solved and fixed, the timer starts.

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.

If the bug report is a non-issue (like, a false report) then the Version: line should be NOT added to the mail.

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. ;)