STOP! Perché questa guida si trova sotto la pagina Cestino?. Una guida può essere cestinata dal Gruppo Documentazione se contiene istruzioni compatibili solo con rilasci non più supportati di Ubuntu oppure perché non si ha certezza che lo siano per i rilasci attualmente supportati. Queste pagine richiedono un aggiornamento e una verifica delle istruzioni contenute. Se vuoi riesumare una di queste guide contatta il Gruppo Documentazione nella board sul forum. |
Indice delle altre pagine
|
|
Indice |
Come in un ospedale, in cui il triage avviene dall'istante in cui un paziente entra nella struttura, vengono monitorati i suoi segni vitali e vengono curati i suoi sintomi, con i bug è molto simile. A parte il rischio di non uscire più dall'ospedale!
Ogni giorno vengono segnalati moltissimi bug in Ubuntu attraverso il software per il tracciamento dei bug Malone. Ogni singolo bug deve essere analizzato e classificato prima di poter essere sistemato. Ed è qui che anche tu puoi dare una mano!
Bug ''untriaged''
I bug untriaged (non smistati), possono essere trovati a questo collegamento: clicca qui. Una volta eseguito il triage del bug, questo non comparirà più all'interno dell'elenco.
È possibile utilizzare la ricerca avanzata di Malone (fare clic su «Advanced search») per trovare i bug non ancora smistati per uno specifico pacchetto. Poi, basta spostarsi nella pagina del bug del pacchetto in questione e cercare:
Status: Unconfirmed
Importance: Undecided
Assigned to: Nobody
Nuovi bug
Qualsiasi segnalazione di un bug, alla fine, è una "conversazione" con colui che ha riportato il bug. Il primo contatto di colui che riporta il bug solitamente avviene con un triager, che cerca di completare la segnalazione del bug. In questa fase è molto importante essere gentili, in qualsiasi circostanza. Cercate di usare un buon inglese nello scrivere!
Per eseguire il triage dei bug è necessario scovarli. Per fortuna questo è abbastanza facile. È possibile venire a conoscenza dei nuovi bug in due modi:
entrando nel canale IRC #ubuntu-bugs sul server irc.freenode.net
iscrivendosi a questa mailing list: ubuntu-bugs (attenzione, molto trafficata!)
Il primo metodo è il preferito, visto che non si avrà la propria mail intasata.
Quando si entra nel canale #ubuntu-bugs, si vedrà un messaggio del tipo:
New bug: #1 in Ubuntu "Microsoft has a majority market share" [Undecided,Unconfirmed] http://launchpad.net/bugs/1
Giusto per iniziare, scegli uno dei bug più recenti e apri il collegamento nel tuo browser preferito. Se nessun altro ha lasciato un commento... allora il bug è tuo!
Duplicati
Molte delle segnalazioni di bug fatte in Ubuntu risultano essere dei duplicati. Solitamente questo avviene quando un bug molto importante e fastidioso è stato introdotto in Ubuntu, causando la segnalazione da parte di molti utenti. Altre volte, gli utenti segnalano un duplicato di un vecchi bug, ma che presenta dei "sintomi" diversi.
Due bug risultano dei duplicati quando presentano la stessa causa. Riuscire a determinare quando due bug sono duplicati sarà più facile quando si conosce meglio un determinato programma o pacchetto. I bug, comunque, non sono per forza dei duplicati se presentano gli stessi effetti. Quando in dubbio... meglio chiedere un'altra opinione!
Quando si osserva un nuovo bug per la prima volta, può essere utile cercare un bug esistente che possa descrivere quello nuovo. Ecco come:
fare clic su «Show all open bugs» sulla destra della pagina,
- cercare i bug con una descrizione simile o un argomento simile,
- se descrivono lo stesso problema, decidere qualche deve essere il principale. Dovrebbe essere quello più comprensibile,
nell'altra segnalazione aggiungere un commento ringraziando l'utente per la sua segnalazione. Quindi fare clic su «Mark as Duplicate» e inserire il numero del bug principale.
Segnalazioni complete
È necessario assicurarsi che ogni singolo bug triaged sia descritto in tutti i suoi dettagli prima di venir preso in consegna da qualcuno che lo debba sistemare. Quando una segnalazione di un bug è corredata da tutte le informazioni possibili, è molto più semplice isolare il problema e rilasciarne il fix.
Per essere completa, una segnalazione di un bug deve comprendere:
- i passi che l'utente ha compiuto per ottenere il problema,
- il risultato atteso dalle azioni compiute,
- il risultato ottenuto,
- la versione di Ubuntu e la versione del programma in uso.
Come un triager, è necessario chiedere ulteriori informazioni qualora sia necessario. Per esempio:
- il numero di versione dei programmi,
- qualsiasi dump dei crash di questi programmi,
- l'output dei sistemi di debug o di backtrace,
- qualsiasi file di log relativo al programma.
Dato che molte delle segnalazioni non saranno complete, è necessario instaurare una conversazione. Chiedi al segnalatore del bug le altre informazioni e quindi:
- fai clic sul nome del pacchetto,
cambia lo «Status» in «Need Info»,
cambia la voce «Assigned to» in «Me»,
seleziona «E-mail me about changes to this bug report»,
chiedi maggiori informazioni, lasciando un commento in «Comment on this change»,
fai clic su «Save changes».
Confermare
Quando avrai un segnalazione completa, con le informazioni sufficienti alla soluzione del bug, potrai confermare il tutto. Come si fa a capire se le informazioni presenti sono sufficienti? Ecco alcuni criteri:
- C'è una patch che risolve il bug?
- Ci sono abbastanza file di log e dump dei crash?
- Puoi riprodurre il bug?
- Un'altra distribuzione ha un bug uguale già confermato?
- L'autore del programma ha segnalato il bug?
Se almeno una di queste condizioni è soddisfatta, puoi confermare la segnalazione. Per fare questo:
modifica il campo «Status» in «Confirmed»,
assegna l'appropriata importanza per il bug come descritto in Bug/Importanza,
modifica il campo «Assigned to» in «Nobody»,
fai clic su «Save changes».
Stato e importanza
Se in dubbio, il maintainer o la persona che sta lavorando al bug dovrebbe cambiare lo stato e l'importanza. Questo solitamente rispecchia l'andamento del lavoro su questo bug.
Controlla la pagina Bug/Importanza e guarda la sezione "Managing Status" presente Bugs/CommonTasks sul wiki internazionale.
Nel caso in cui una segnalazione di un bug incorpori anche una patch, questo non significa che lo stato del bug debba essere impostato a «Fix Committed». Si veda la sezione "Managing Status" della pagina CommonTasks per ulteriori informazioni.
Informare upstream
La maggior parte del software presente in Ubuntu non viene scritto da noi. Noi pacchettizziamo molti programmi, li ragguruppiamo in una distribuzione e le integriamo. Per questo, molti bug sono relativi a programmi che non sono scritti da noi.
È giusto collaborare con chi scrive il software. Per questo è necessario informare anche gli autori originali del software, così possono venire a conoscenza dei bug nel loro software.
Passare un bug in upstream è un lavoraccio, ma è giusto farlo. Ecco cosa bisogna fare:
- trovare l'autore upstream,
- se dispongono di un sistema per il tracciamento dei bug:
- iscriversi se necessario,
- cercare un bug simile,
- se non esiste aprirne uno nuovo,
- collegare il loro bug con quello in Ubuntu.
- se dispongono di una mailing list o di un indirizzo email:
- segnalare il bug inviando una mail agli indirizzi appropriati.
Quando si segnala un nuovo bug, aggiungere sempre le seguenti informazioni:
collegamento al bug in Malone come:
https://launchpad.net/bugs/######
- l'autore originale della segnalazione,
- una descrizione completa del problema.
Collegare una segnalazione di un bug è molto semplice:
fare clic su «+ Upstream» o su «+ Distribution»,
scegliere il «Product» o la «Distribution» corretti,
selezionare «Link to a bug in another bug tracker:»,
inserire il numero identificativo del bug nel campo «Remote Bug»,
fare clic su «Continue».
Se il sistema per il tracciamento dei bug da utilizzare non è ancora registrato con Malone, dovresti aggiungerlo.
Rifiutati
Qualche volta dovrai anche rifiutare una segnalazione. Questo può essere dovuto dal fatto che il problema non è riproducibile, il programma è stato progettato per comportarsi in un certo modo oppure il bug è una richiesta di una nuova caratteristica o di supporto.
La cosa migliore da fare in questi casi è quella di respingere gentilmente la segnalazione, ringraziando comunque il segnalatore. A questa pagina è possibile trovare delle risposte utili da utilizzare: Bug/Risposte.
Non è necessario rifiutare un bug già identificato come un duplicato. Un domani potrebbe essere necessario riaprire il bug.
Controllare i propri bug
Potrebbe capitare che alcuni segnaltori di bug non rispondano mai, e si potrebbe pensare di respingere il bug.
Qualche volta basta guardare nella propria lista dei bug per vedere se qualcuno ha riposto.
Per vedere questi bug, basta andare su Launchapd all'indirizzo:
https://launchpad.net/~<username>/+assignedbugs
dove:
<username>
va sostituito con il proprio nome utente.
È utile andare a rivedere i propri bug abbastanza spesso, almeno una volta la settimana, così da non perdersi niente!
Ulteriori risorse
Documento originale: Bugs/HowToTriage
