Traduzioni: English - Français - Italiano



Come usare il sistema di tracciamento dei bug (BTS)

Seminario online organizzato da Debian Women e tenuto su IRC da Gerfried Fuchs, 09-Dec-2010

Questa è una guida all'uso del Sistema di tracciamento dei bug (BTS, Bug Tracking System).

L'acronimo BTS sta per Bug Tracking System ed è dove Debian conserva e traccia i bug segnalati (incluse le segnalazioni delle funzionalità desiderate (wishlist), che non sono veri e propri bug). È principalmente un sistema di posta elettronica: di fatto controllarlo e manipolarlo può essere fatto solamente mandando e-mail al sistema. I messaggi di posta devono essere inviati in formato solo testo e non in formato HTML.

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 si possono interrogare le segnalazioni sui bug piuttosto rapidamente (a meno che il server non sia troppo carico) ed è anche estremamente comodo.

Andando su http://bugs.debian.org/ si verrà reindirizzati ad una pagina che offre un modulo dal quale si possono eseguire delle ricerche, ma la parte più utile sono i vari specifici reindirizzamenti che offre.

In cima alle pagine panoramiche c'è un elenco di categorie di segnalazioni di bug (per gravità e stato); in fondo alla pagina c'è un altro modulo che permette di allargare o restringere la propria ricerca usando parole chiave o proprietà del bug, come lo stato o l'età.

In più, si noti che nella sezione principale della pagina panoramica immediatamente dopo i numeri dei bug c'è una serie criptica di caratteri e simboli racchiusi tra parentesi quadre. È sufficiente posizionare il mouse su uno di questi simboli per ottenere un suggerimento che spiega cosa significhi, cliccandolo si fa aprire una finestra a comparsa contente ulteriori informazioni sul bug in questione.

Questo è una breve introduzione all'interfaccia web. Non dimenticare che è in grado solamente di recuperare informazioni sui bug, quindi ci si può sentire liberi di cliccare in giro: non può accadere nulla di male.

Segnalare i bug: reportbug

Per la segnalazione dei bug è necessario un programma di posta elettronica oppure, cosa molto più comoda, si può usare lo strumento reportbug. reportbug è principalmente uno strumento testuale (ma ci sono due interfacce grafiche: basate su urwid e GTK+). Esiste anche reportbug-ng che è uno strumento completamente distinto, con un'interfaccia grafica che mira a fare le stesse cose.

Entrambi funzionano al meglio con un MTA (Mail Transport Agent) locale come postfix, exim o ssmtp. Informazioni su come configurarli vanno cercate altrove.

Anche se non si dispone di un MTA locale, reportbug è ancora molto utile dato che ha l'opzione {--template}}}. Questo aiuterà a produrre informazioni per la segnalazione di bug che il manutentore del pacchetto richiederebbe in ogni caso, come le versioni del pacchetto con il bug e dei pacchetti da cui dipende. sulle dipendenze o simili.

Per provarlo basta lanciare nel terminale:

reportbug --template pacchetto

con il nome di un pacchetto che è installato. Non ci si preoccupi, non fa nulla di pericoloso, mostra solo alcune righe di testo :)

Guardando l'output, si possono vedere diverse cose importanti che dovrebbero essere presenti in ogni email di segnalazione di bug. come prima cosa c'è l'indirizzo a cui inviare la segnalazione:

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

L'indirizzo submit@bugs.debian.org è dove vengono mandate le nuove segnalazioni. Ovviamente nella segnalazione si deve inserire un titolo utile e descrittivo che dia al manutentore del pacchetto una prima idea su quale sia il problema. (Il predefinito Subject: none (Oggetto: nessuno) non è molto utile!)

Poi c'è un altro blocco che comincia con Package: e ha una riga Version: e una Severity::

I primi tre (grave, critical e serious) sono considerati critici per il rilascio e definiscono un speciale gruppo di segnalazioni. Se si è in dubbio, non usarli almeno che non si sia sicuri del loro significato, alcune persone potrebbero reagire nervosamente se vengono utilizzati per segnalazioni che alla fine non sono tanto gravi. Si ritornerà sul significato speciale delle segnalazioni di bug critici per il rilascio più tardi.

wishlist è la gravità da usare per i miglioramenti che si vorrebbero vedere in un pacchetto. Ci si prepari al fatto che alcuni manutentori di pacchetti potrebbero suggere di segnalarli direttamente agli autori originali; anche se, personalmente, l'autore di questa guida ritiene che i manutentori di pacchetti debbano fungere da collegamento e da tramite tra gli utenti Debian e gli sviluppatori originali.

Infine, è bene ricordare che si deve cercare di essere descrittivi non solo nel titolo del bug, ma anche nel corpo della segnalazione; ancora meglio sarebbe includere il modo per riprodurre il bug.

Per una descrizione più sistematica di come segnalare i bug, vedere http://www.debian.org/Bugs/Reporting, che fornisce anche più informazioni sui campi pseudo-intestazione e su cosa dovrebbe essere incluso nel corpo della segnalazione.

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

Per modificare le segnalazioni dei bug, c'è l'indirizzo e-mail control@bugs.debian.org. L'intero sistema di tracciamento dei bug è aperto a chiunque, così come questo indirizzo di posta elettronica. Questo significa che qualsiasi persona è tecnicamente in grado di modificare qualsiasi segnalazione di bug. L'indirizzo di controllo è dove inizia il divertimento. Funziona anche come l'indirizzo per la segnalazione per ciò che riguarda le prime righe della segnalazione.

La documentazione per questo indirizzo può essere trovata su http://www.debian.org/Bugs/server-control.

Normalmente la sintassi è:

 comando numerobug argomenti

e il numero di argomenti varia a seconda dei comandi:

Quindi con retitle:

retitle 12345 nuovo-titolo

si imposta il titolo della segnalazione 12345 a nuovo-titolo.

Non ci preoccupi, non può essere fatto per questo numero di segnalazione, il bug è già stato archiviato. Si possono modificare solo le segnalazioni non ancora archiviate.

Un comando usato spesso è reassign che indica il fatto che un bug appartiene ad un altro pacchetto. Questo comando accetta un secondo argomento dopo il nome del pacchetto: il numero di versione. Se si sa quale è la versione dell'altro pacchetto affetta dal bug si dovrebbe includerla così che il tracciamento di versione possa continuare a funzionare. Il tracciamento di versione verrà spiegato in seguito, insieme ad alcuni esempi per mostrare come funzioni. :)

Il comando tag aiuta a classificare i bug. In effetti segnalando i bug si può aggiungere anche Tags: ai campi nella pseudo-intestazione e impostare già etichette (tag) specifiche per una segnalazione.

Alcune delle etichette usate più frequentemente sono:

L'elenco completo delle etichette può essere consultato su http://www.debian.org/Bugs/Developer#tags.

I messaggi per l'indirizzo di controllo vengono archiviati nel BTS, ma non vengono inviati a nessun'altra destinazione, perciò si può vedere che tali messaggi di controllo hanno l'intestazione Cc impostata a numerobug@bugs.debian.org. Questi messaggi vengono inviati al manutentore del pacchetto (e alle altre persone iscritte a quel bug).

Se ci si vuole iscrivere ad una specifica segnalazione, si mandi un messaggio a numerobug-subscribe@bugs.debian.org. Si riceverà un messaggio con le istruzioni per confermare l'iscrizione, una volta fatto da quel punto in poi si riceveranno tutte le email mandate a quella segnalazione di bug. Ci si può anche iscrivere alle segnalazioni di tutti i bug di uno specifico pacchetto attraverso il PTS (Package Tracking System, sistema di tracciamento dei pacchetti) andando su http://packages.qa.debian.org/NOMEPACCHETTO (sostituendo a NOMEPACCHETTO il nome del pacchetto desiderato). In basso a sinistra c'è il modulo di iscrizione.

Naturalmente i messaggi di posta sia per control@bugs sia per numerobug@bugs contengono sia comandi per il server di controllo, sia informazioni per le persone. Per non confondere lo strumento che analizza i messaggi di controllo con il testo pensato per le persone c'è un comando speciale thanks che forse il lettore avrà già notato dopo i comandi di controllo. Dice all'analizzatore di fermare l'analisi dell'email da quel punto in poi. Avere riguardo per l'analizzatore dei messaggi e usare "thanks" per terminare i messaggi di controllo.

Inoltre notare che è stato detto che le email mandate a numerobug@bugs vengono inviate al manutentore del pacchetto (e alle persone iscritte al bug). Queste email NON vengono mandate a chi ha originariamente segnalato il bug! Questa è una cosa che potrebbe essere cambiata in futuro, ma per il momento si deve scovare il mittente della segnalazione del bug e aggiungerlo esplicitamente ai destinatari oppure utilizzare un altro indirizzo di posta elettronica di comodo: bugnumber-submitter@bugs.debian.org.

Tracciamento di versione

Cos'è di fatto il tracciamento di versione?

BTS tiene traccia della versione in cui è stato risolto un bug, di quali rilasci siano affetti da un bug e altre cose simili. Per questo il campo Version: nella pseudo-intestazione è molto importante nella segnalazione di un bug. Altrimenti il BTS potrebbe invece pensare che interessa tutte le versioni di un pacchetto.

Questo è il posto giusto per tornare a parlare del gruppo speciale dei bug critici per il rilascio che sono stati nominati in precedenza. Le segnalazioni di bug infatti possono venire archiviate dopo 28 giorni se soddisfano determinati criteri: di norma un bug deve essere risolto sia in unstable sia in testing per andare in archivio.

Naturalmente ciò vale solo se i bug riguardano entrambi i rilasci: una segnalazione che interessa solo unstable, ma non testing (a causa di una diversa versione) può venire archiviata immediatamente, se è stato creato un pacchetto per tutte le architetture.

Quindi la distribuzione colpita è un criterio, l'architettura è l'altro. Se entrambi i criteri solo soddisfatti, il conto alla rovescia comincia.

Le segnalazioni posso essere chiuse i molti modi. Quello più comune è il caricamento di un pacchetto che contiene una voce closes: #12345 nel changelog. Quando il pacchetto è accettato nell'archivio, viene automaticamente mandato un messaggio a 12345-done@bugs.debian.org con Version: 1.2.3 nella prima riga. Questo ovviamente può essere fatto anche a mano: si può mandare una email a numerobug-done@bugs con il campo Version: dell'intestazione che informa della chiusura del bug in quella versione.

Se la segnalazione di bug riguarda un "non problema" (come, una falsa segnalazione), l'intestazione Version: NON deve essere aggiunta al messaggio.

Questa differenza è necessaria perché il BTS deve essere in grado di distinguere i bug chiusi in una specifica versione da quelli che non sono realmente bug.

L'interfaccia web del BTS ha una funzionalità davvero molto utile per tutto questo: il grafo di versione. Lo si potrebbe già aver notato in alcune segnalazioni di bug, nell'angolo in alto a destra. Si compone di vari riquadri: quelli rotondi rossi e quelli verde quadrati. Quelle verdi sono le versioni in cui il bug è risolto, quelle rosse sono le versioni interessate.

Come già detto in precedenza, non si esiti a cliccare in giro, anche sui grafi di versione. Questo migliorerà immensamente la loro leggibilità. ;)

Esempio 1

Ecco un grafico di bug semplice:

istantanea di una segnalazione di bug per il bug #598227 come appariva prima della stesura di questa guida

Questo grafico è molto semplice, ce ne sono di molto complessi con diversi rami. Si vede in cima il riquadro verde e anche i rilasci interessati (testing, unstable) e sotto il cerchio rosso (stable). Sulla sinistra si può leggere "Severity: grave" che indica la gravità. Questa è una segnalazione di bug critico per il rilascio. Questo è il motivo per cui il bug non è stato ancora archiviato.

Leggendo la segnalazione di bug sembra che interessi erroneamente stable: icedove 3 non fa parte di stable, perciò questa segnalazione di bug non è ha gravità grave per stable. Dato che non si può impostare la severità in base al rilascio, qui entrano in gioco le etichette dei bug menzionate in precedenza.

Ci sono etichette per le distribuzioni. Durante il mio lavoro teso a ridurre il numero dei bug critici per il rilascio in stable, l'autore si è imbattuto in molte di queste segnalazioni. Etichettando questa segnalazione con

 tag 598274 + squeeze sid

fara sì che sia marcata come segnalazione che _non_ ha effetto su Lenny.

Se una segnalazione di bug ha un'etichetta di rilascio il BTS considera il bug come problema che ha effetto solamente i rilasci specificati. Se si ha un MTA locale e la variabile d'ambiente DEBEMAIL è impostata, c'è uno strumento estremamente utile nel pacchetto devscripts: si chiama bts - dal nome si può indovinare a cosa serve.

bts è un client a riga di comando per il BTS e si può inviare un messaggio email di controllo sul problema descritto usando questa riga di comando:

bts tag 598274 + squeeze sid  '# not relevant for stable'

Perciò, leggendo più in avanti nella segnalazione di bug sembra che la versione 0.7.3-3 in cui il problema è stato risolto è stata impostata erroneamente e andrebbe rimossa:

bts notfound 598274 0.7.3-3

In realtà questo tipo di comandi possono essere concatenati e combinati nello strumento bts, separandoli con punti.

Ciò è particolarmente utile quando si fanno diverse cose contemporaneamente, viene prodotto un solo messaggio email e non svariati.

Se si ricarica la pagina del bug si vedrà che le etichette sono già impostate. Non sembra che nient'altro sia cambiato, non è vero? Qualcosa è cambiato: se si fa clic su icedove-bidiui in alto per ottenere la pagina con la panoramica dei bug per quel pacchetto e poi si fa clic sulla parte [G|u|☺] nella descrizione breve del bug, si vedrà che il bug può venire archiviato in 28 giorni! Urra!! si è appena chiuso un bug critico per il rilascio, proprio durante questa esercitazione :)

Esempio 2

Si guardi questo bug:

istantanea della pagina web della segnalazione di bug #606327 prima di questo tutorial

Di fatto questo bug ha un aspetto un po' strano. Il messaggio iniziale non contiene un campo Version: nell'intestazione; non c'è alcun grafo e nella sintesi in cima non c'è alcuna informazione sulla versione. Scorrendo la pagina in basso si può vedere cosa è successo.

Immediatamente dopo il messaggio iniziale si può notare due piccole voci contenenti Bug reassigned e specialmente Bug No longer marked as found in versions. Ecco qui! Ha perso l'informazione sulla versione a causa di un'azione reassign! È stato detto in precedenza che un'azione reassign può in pratica accettare un argomento agguntivo che è un numero di versione. Sfortunatamente qui non è stato usato.

istantanea del messaggio "Bug Reassigned" nella pagina web della segnalazione di bug #606327

Controllando bene, si vede che la cosa è ancor più strana. Il bug è stato riassegnato da open-vm-dkms a open-vm-tools. Sono correlati? Se si investiga un po' di più, si scopre che uno è il nome del pacchetto sorgente e l'altro è il nome del pacchetto binario creato dal sorgente medesimo. Perciò, di fatto, dovrebbero avere la stessa informazione di versione, non è così? Cosa fare adesso?

bts found 606327 2010.06.16-268169-3 '# re-add version information lost in reassign'

Bisogna aspettare un po' perché abbia effetto. Dopo aver atteso, se si ricarica la pagina, si vede che è apparso un grafo del bug e che contiene solo (testing, unstable). Il bug non riguarda più stable. Secondo baco critico per il rilascio in stable spiaccicato! :)

Esempio 3

Guardare la segnalazione di bug successiva.

istantanea della pagina web della segnalazione di bug #605784

Questo grafo di bug ha semlicemente una sola versione. Il pacchetto non sembra essere stato aggiornato dal rilascio di Lenny!

Perciò il BTS non ha alcuna possibilità, almeno guardando la sola informazione sulla versione, di discernere se questo bug ha effetto su stable o no. Ancora una volta ha bisogno dell'aiuto dell'etichette per i rilasci. Leggendo la prima riga della segnalazione di bug: after upgrade to squeeze (dopo l'aggiornamento a squeeze), questa suggerisce subito che il bug non ha in realtà effetto su stable.

Perciò ancora una volta si etichetterà il bug con + squeeze sid. :) Dopo aver atteso un po', si vede che il grafico di versione nella pagina del bug non è cambiato per nulla. Questo è corretto, ma le etichette relative ai rilasci sono state impostate, perciò il bug non è più considerato come uno che ha effetto su stable. :) Terzo baco critico per il rilascio in stable spiaccicato!

Esempio 4

Ora un problema un po' più complicato; fino ad ora si sono visti tutti casi semplici.

Guardare questa segnalazione di bug:

istantanea della pagina web della segnalazione di bug #507360

Questo bug è marcato come chiuso sin da febbraio! Sono passati decisamente più di 28 giorni! Cosa sta succedendo?

Nelle informazioni in alto a sinistra troviamo elencate una versione in cui il bug è stato trovato e una in cui è stato risolto. Inoltre il grafo è completamente rosso. Dov'è la parte verde? Come già detto, si può cliccare sul grafico. Questo non dà ancora più informazioni, ma si può espandere il grafo usando [Don't collapse].

istantanea del grafo di versione espanso per il bug #507360

È stato risolto nella versione 2.28.0-1. Ma dove si può trovare 2.28.0-1 nel grafo? Non è una questione di bontà di vista e di certo si può convenire che nel grafo non c'è quella versione. Cosa è successo? Come si può vedere il bug non è stato chiuso con un caricamento, ma con un semplice messaggio di posta.

Può facilmente capitare che qualcuno si confonda di versione in questi casi e sembra proprio che sia ciò che è accaduto in questo caso. Dato che anche il PTS non ha quella versione nella sua cronologia: http://packages.qa.debian.org/g/gnome-media.html

si deve semplicemente correggere l'informazione sulla versione. Usando un approccio conservativo si può marcare il bug come risolto in 2.28.1-1 che è stata la versione caricata successiva a quella in cui si diceva che il bug fosse stato risolto:

bts notfound 507360 2.28.0-1 '# fixing version information' . found 507360 2.28.1-1

Un simile problema vale per 418597; anche in questo caso si deve cercare la versione corretta in cui il bug è stato risolto.

In realtà sembra che ci siano alcuni altre sviste nel pacchetto gnome-media, perciò è stato inviato ad uno dei manutentori del pacchetto un messaggio che invitava a sfogliare i bug e controllarli. :)

Quelli non sono bug critici per il rilascio, ma bug che comunque non sono stati chiusi per bene a causa del tracciamento di versione.

Esempio 5

Ora, un altro tipo di problemi: http://bugs.debian.org/src:logrotate. Questo pacchetto ha un bel numero di versioni già corrette. Cliccando sull'etichetta del bug per ottenere le informazioni a comparsa aggiuntive, si vede che i bug sono chiusi da... eoni? Cosa? Cosa sta succedendo?

Controllare il bug 388608. L'informazione a comparsa riporta Modified 1 year and 116 days ago (Modificato 1 anno e 116 giorni fa). Accipicchia! Ben più di 28 giorni, si direbbe. ;)

Controllare il grafo del bug.

istantanea della pagina web del grafo di versione del bug #388608

Sembra impossibile che qualcuno riesca a leggerlo così, perciò cliccarci sopra. :) In cima, c'è (testing, unstable) nel riquadro verde. Ma cosa succede? C'è un altro unstable in un cerchio rosso più in basso! Come può essere che ci siano due versioni unstable?

Controllando la pagina del pacchetto: http://packages.debian.org/unstable/logrotate, se si scorre fino alla fine della pagina, si trova l'informazione sulla versione. Anche qui è usato un codice basato su colori: verde significa sincronizzato, giallo è indietro rispetto alla versione Debian e rosso è indietro rispetto alla versione originale. Si può tranquillamente ignorare il giallo in m68k perché non è un "port ufficiale".

La versione colpevole è in hurd-i386, è la 3.7.1-5 e quella era anche la versione nel cerchio con (stable, unstable) nel grafo del bug!

istantanea della pagina web del pacchetto logrotate con informazioni sulla versione per tutte le architetture

Cosa si può fare? O si trova una persona che lavora al port di hurd che compili la versione recente del pacchetto, o si può chiedere a uno dei gentili amministratori ftp di rimuovere il pacchetto in hurd-i386. Ciò può essere fatto usando "Report bug" (segnala bug) per ftp.debian.org; si viene guidati in un sistema a menu per questo pseudo-pacchetto che rende estremamente facile richiedere anche queste rimozioni parziali di pacchetti.

Di solito, l'autore seleziona RoQA (Request of Quality Assurance, richiesta di controllo di qualità) perché il QA team (team del controllo di qualità) è formato da tutti, incluso chi sta leggendo questa pagina. Sì, è fatto da tutti coloro che hanno a cuore Debian.

Questo pacchetto ha lo stesso problema: http://bugs.debian.org/src:distcc. L'autore ha inoltrato una richiesta di rimozione per hurd-i386 su distcc poco prima di questo tutorial e, dato i membri del gruppo degli amministratori ftp sono piuttosto veloci, la cosa era già stata fatta quando è stata tenuta questa lezione.

Se si clicca sulle informazioni per quei bug, si vede che verranno archiviati presto :)

UDD

In caso ci si chieda come l'autore abbia fatto a trovare gli esempi: ha usato UDD.

UDD è il Ultimate Debian Database (database Debian definitvo) e può essere interrogato per qualsiasi informazione si possa pensare.

Il primo è l'elenco di segnalazioni di bug critici per il rilascio di stable ancora aperti (che al momento della stesura di questo documento possono anche essere interrogati usando http://udd.debian.org/bugs.cgi) e selezionando in cima Lenny. Il secondo è semplicemente un riassunto delle segnalazioni di bug che erano chiusi di già l'anno scorso e che ancora non sono stati archiviati.

Domande e risposte

D: Esiste una regola per il titolo di un bug?

R: In generale, no. Alcuni pacchetti (o piuttosto pseudo-pacchetti) usano il titolo del bug per elaborazioni automatiche e preferiscono una speciale formattazione del titolo. Di solito queste persone sanno che non è facile conoscere queste informazioni perciò non si innervosiscono se si sbaglia il titolo.

Uno di questi (pseudo-)pacchetti speciali è ftp.debian.org. Hanno dei requisiti speciali per il titolo in modo che sanno cosa fare guardando semplicemente il titolo della segnalazione di bug, invece di scorrere tutto il corpo che è fatto solo da informazioni aggiuntive.

D: Chi e come può cambiare la severità di una segnalazione di bug esistente (segnalata in precedenza)?

R: Questo ci riporta all'indirizzo di posta elettronica speciale, control@bugs.debian.org

D: Quanto importante è la "Politica APT" per una segnalazione di bug?

R: A dire il vero, l'autore non è certo di cosa si volesse intendere in questo caso con "Politica APT", e ha chiesto una ulteriore precisazione della domanda, dato che era la prima volta che sentisse nominare quel termine, in particolare in relazione alle segnalazioni di bug.

Ipotizzava ci si potesse riferire alla riga "APT policy" che reportbug aggiunge solitamente quando segnala un bug per un pacchetto (riassunto delle informazioni di apt-cache policy).

Ritornando all'output di reportbug --template :) L'attuale segnalazione di bug dovrebbe essere messa tra il blocco con Package, Version e Severity, e la parte restante che inizia con System Information.

Il blocco System Information aiuta il manutentore a scovare i problemi, che potrebbero essere dovuti a speciali dipendenze o impostazioni dovute a debconf o al kernel in uso. Quando la segnalazione di bug è di per sé molto dettagliata, queste System Information di solito non vengono usate e non sono affatto necessarie. Ma piuttosto spesso, alcuni inviano segnalazioni di bug con informazioni carenti (non intenzionalmente) e quindi queste System Information possono dare un buon suggerimento sulla direzione in cui investigare.

L'autore sperava che questa risposta rispondesse in maniera abbastanza utile alla domanda :)

In ogni caso, ...

D: Nell'output di "reportbug --template nome-pacchetto" in System Information : APT policy: (500, 'stable').

R: Sì, proprio come immaginato dall'autore. Questo è il valore predefinito che gli utenti di stable invieranno. Gli utenti possono avere impostati altri repository nel proprio sources.list e aver modificato le preferenze in modo che i pacchetti da un rilascio specifico siano preferiti in fase di installazione. Questa è un'informazione interna di apt, ma utile (in aggiunta alla versione del pacchetto) per i manutentori del pacchetto per vedere in quale ambiente si stia verificando il bug.

D: È possibile fare tutte le azioni control-server usando campi nella pseudo-intestazione in un messaggio di posta elettronica a numerobug@b.d.o o è necessario utilizzare control@b.d.o?

R: È necessario utilizzare un messaggio di posta esplicito per control@, non viene fatta un'elaborazione automatica. Per quanto a conoscenza dell'autore, ci si sta lavorando ma ci potrebbe volere un po' di tempo prima che il sistema sia affidabile e non faccia qualcosa che non dovrebbe.

D: 28 giorni dalla segnalazione? o dall'ultima modifica?

R: La risposta è nella sezione Tracciamento di versione.

D: Il bug è segnalato come risolto in 0.7.3-3, che è anche la versione in stable. Perché il BTS pensa sempre che abbia effetto su stable?

R: Buonissssssima domanda. :) L'autore aspettava proprio questa domanda. ;) Vedere la riga prima di quella: è anche stato trovato nella stessa versione. Dato che un bug non può essere trovato e risolto nella stessa versione, il BTS si sta comportando in modo cauto e rimuove entrambe le informazioni considerandole come non esistenti.

D: E gli attacchi al sistema di tracciamento dei bug, per esempio mirati a chiudere o riaprire, ecc. bug in modo scorretto?

R: A dire il vero alcuni messaggi di spam sono riusciti a mandare messaggi agli indirizzi -done. Questi vengono di solito intercettati facilmente, e dato che qualunque cosa può essere annullata facilmente, non è un problema. I manutentori dei pacchetti di solito li notano e prendono contromisure, così come fanno regolarmente gli amministratori del BTS.

Gli amministratori del BTS hanno anche la possibilità di impedire ad alcuni mittenti di lavorare con il sistema di tracciamento dei bug in caso facciano intenzionalmente azioni deleterie.

Ma i pregi di di essere aperto e che tutti siano benvenuti a lavorare sui bug, superano di gran lunga i problemi che a volte derivano dall'uso scorretto del bot di controllo.

D: Nel caso trattato non avrebbe dovuto essere (non)risolto invece di (non)trovato?

R: È una cosa buona che si ripensi agli esempi trattati, e, sì, la domanda è naturalmente corretta. Tuttavia non verrà inviato un altro messaggio di controllo perché in pratica non ha importanza. Il "risolto" sbagliato non ha effetto su nulla, perciò l'autore ha lasciato le cose come stavano per non disturbare i manutentori del pacchetto :)

Vedere anche