Il triage è un sistema utilizzato per selezionare i soggetti coinvolti in infortuni, gravi o leggeri che siano, secondo classi di urgenza/emergenza crescenti, in base alla gravità delle lesioni riportate o del loro quadro clinico. Questo concetto è ripreso dalla computer science per catalogare i bachi di un programma secondo la priorità, soprattutto nel caso che questi siamo sviluppati da una comunità di volontari, dove quindi le forze in campo sono molto limiate e preziose.
Un bug mai segnalato prima è classificato come nuovo fino a quando qualcuno non lo riesce a riprodurre (o, purtroppo, vi incappa involontariamente e lo segnala), ed il baco diventa confermato. Vi sono poi altre categorie di classificazione come risolto, informazioni aggiuntive richieste, ben segnalato, ecc…
La prima cosa da fare per risolvere un baco è se qualcun altro (di un’altra comunità) lo ha risolto. Nel caso di Ubuntu ad esempio andando a vedere se in Debian è stato riscontrato e risolto (dato che il 75% dei pacchetti è comune) ed il contrario. Oppure se il pacchette è ad esempio OpenOffice.org se la comunità di OOo lo ha riscontrato e risolto (potrebbe ad esempio affliggere tutti i pacchetti di quell’applicazione, siano essi per Windows, per Mac OSX, o per qualunque altro SO).
Gli sviluppatori chiedono agli utenti di seguire alcune semplici indicazioni per “non farli arrabbiare”
- nel momento della segnalazione riportare tutte le informazioni necessarie alla riproduzione del baco; tipo il modello della macchina sulla quale si è riscontrato un problema nella gestione della batteria;
- nel momento della segnalazione NON riportare informazioni superflue: tipo il modello della macchina sulla quale è stato riscontrato un errore di traduzione;
- scrivere in inglese;
- scrivere in modo schematico: del tipo: ho fatto questo, poi quest’altro ed è successo questo;
- scrivere nel posto giusto: se Inkscape ha un baco sia nella versione per GNU/Linux che in quella per Windows segnalarlo all’autore di Inscape, mentre se il problema si presenta solo con la versione per Debian segnalarlo alla Comunità del SO;
- segnalare la reale priorità/gravità del baco. La segnalazione di una falsa priorità aumenterà solo il lavoro degli sviluppatori, che dovranno correggere la priorità riportandola al corretto livello, senza aumentare le probabilità che il problema venga corretto in tempi più brevi: lo sviluppatore, dopo aver corretto il livello di priorità della segnalazione passerà ad un bug più grave.
- seguire la segnalazione, rispondendo ad eventuali richieste dello sviluppatore per completare la segnalazione (anche se la segnalazione del tutto corretta);
- rispondere con precisione alle domande che ci vengono poste: dire l’ultima data di aggiornamento del sistema quando ci viene chiesta la versione del kernel in uso non va bene…
Come abbiamo detto nel post precedente, in Debian i bugs segnalati sono consultabili su bugs.debian.org cercando il numero del baco che ci interessa. Ogni baco è taggabile in diversi modi come riportato in http://www.debian.org/Bugs/Developer#tags.
Dal Terminale possiamo lanciare Reportbug che ha tre interfacce: una completamente testuale, una semi-grafica ed una grafica. Per segnalare un bug posso procedere come segue:
- Qual’è il pacchetto che devo segnalare, cioè quello in cui si trova il comando che ha generato in problema?
$ which <COMANDO> <PACCHETTO_DOVE_SI_TROVA_IL_COMANDO>
- Lancio reportbug seguito dal nome del pacchetto trovato al punto 1.
- Controllo i duplicati che mi vengono proposti e decido se sottoscrivere un bug già aperto o se aprirne uno nuovo.
- Per segnalarne uno nuovo, inserisco l’argomento/riassunto che apparirà in BTS (in inglese).
- Scelgo la gravità del baco.
- Inserisco dei TAG (facoltativo).
- scrivo il corpo dell’E-mail, descrivendo il problema (in inglese).
Scriverò una cosa tipo “Ciao a tutti, stavo facendo così e cosà aspettandomi succedesse questo mentre invece è successo quest’altro” inserendo tutte le informazioni di cui dispongo e che ritengo utili.
In Ubuntu la procedura è molto simile anche se più di immediata comprensione dato che tutto passa attraverso un sistema di concezione web 2.0 come è Launchpad.
————————————————————————————————————————————————
Carlo, si potrebbe cercare tra i bug di Ubuntu quel problema dei pannelli che ho sul computer per L’Aquila, ma non ho capito bene come si fa.
Dunque, da bugs.launchpad.net/ come faccio a trovare bachi simili al mio?
Mi devo leggere 700 record?
Se vuoi spulciare fra i bugs prova a passare da https://launchpad.net/ubuntu/+bugs non ho capito la differenza ma funziona meglio.
Ti consiglierei anche di provare a connetterti alla stanza IRC #ubuntu-it su freenode (prova ad usare xchat, è molto comodo).
Ma hai poi provato a dare killall gnome-panel? il problema si è risolto? Secondo me se si risolve così non è un bug vero e proprio e basta che vai sul canale IRC o che scrivi un’Email alla ML del FLUG e ti daranno qualche consiglio per risolvere il tutto.