Segnalare un bug

Da FOL Wiki.
Versione del 17 set 2015 alle 19:10 di GiulioErler (Discussione | contributi) (Flags relativi ad un bug-report)

(diff) ← Versione meno recente | Versione attuale (diff) | Versione più recente → (diff)
L'articolo è in fase di scrittura o modifica !
Warning.png
Il presente articolo è attualmente in fase di scrittura o modifica.
Per qualsiasi proposta o modifica contatta direttamente l'autore.
Autore / Editore : GiulioErler
Di: GiulioErler

Rilettura in corso

Introduzione

Segnalare un bug – baco, “difetto” nello sviluppo del software - è un ottimo modo per contribuire attivamente allo sviluppo del sistema operativo Fedora e dei pacchetti del parco applicativo che compongo la distribuzione. Non esiste infatti prodotto informatico esente da imperfezioni; l'apporto degli utenti risulta quindi fondamentale per accrescerne la qualità.

Home Page di Bugzilla.

Il modo migliore per rendere consapevoli sviluppatori e manutentori quindi, è quello di aprire una segnalazione su Red Hat Bugzilla, la piattaforma di riferimento per l'ecosistema Red Hat.

Creazione account Bugzilla

Il primo passo, è ovviamente quello rappresentato dalla creazione di un account gratuito tramite l'apposita pagina per la registrazione. L'unico dettaglio richiesto è l'indirizzo e-mail, a cui verrà inviato un collegamento ipertestuale per l'attivazione: è consigliabile creare una casella di posta elettronica “ad-hoc” o comunque utilizzarne una differente rispetto a quella personale. I motivi sono sostanzialmente due:

  • Il contatto inserito non sarà celato, in modo da agevolare eventuali comunicazioni private – rare ma possibili – tra i diversi contributori.
  • In seguito ad ogni intervento che interesserà il report aperto, il sistema notificherà all'utente l'evoluzione della situazione tramite mail.


Registrazione a Bugzilla.


Tramite il link inviato automaticamente dal sistema, è opportuno inserire gli ultimi dettagli - nome reale, password, relativa convalida – e confermare per rendere l'account operativo. Va ricordato comunque che, essendo Fedora un progetto esteso a livello mondiale, è necessaria una certa dimestichezza con la lingua inglese, per poter interpretare correttamente richieste e commenti.


Registrazione a Bugzilla.


Quando segnalare un bug

Spesso, quello che potrebbe all'apparenza sembrare un bug, è invece in realtà una caratteristica controversa del software o, più comunemente, un errore di configurazione dell'utente. Una lettura interessante sull'argomento è rappresentata dall'apposita guida ufficiale. Prima di aprire una segnalazione, può essere utile consultare altre risorse, tra le quali:

  • Il forum della comunità italiana Fedora Online: il forum di FOL, frequentato da utenti italiani della distribuzione, racchiude al suo interno una raccolta di svariate problematiche e relative soluzioni. Può inoltre risultare utile l'apertura di un nuovo topic ad-hoc per permettere di inquadrare la situazione.
  • AskFedora: similarmente a quanto accade per l'ecosistema nostrano, questo portale di riferimento rappresenta il punto d'incontro per discussioni internazionali da cui è possibile attingere per reperire informazioni a riguardo del malfunzionamento riscontrato.
  • IRC: per avere un sostegno rapido e diretto, può essere utile porre una domanda veloce sulla chat maggiormente utilizzata dagli utenti di Fedora. I canali di riferimento sono #fedora-it per il panorama italiano, #fedora per quello internazionale e #fedora-qa per discutere in merito della versione Rawhide o dei pre-rilasci. Un elenco completo di tutti i vari canali è presente qui.
  • Mailing List: le mailing list sono speciali indirizzi che rispediscono i messaggi che ricevono a tutti gli utenti iscritti. Qui è possibile consultare la vasta gamma di liste appartenenti al Project.
  • Motori di ricerca: spesso bistrattati ed ignorati, in realtà possono fornire indicazioni soprattutto se affrontati in panorami esterni a Fedora. Forum di discussioni, pagine tecniche di sviluppatori e blog di appassionati possono risultare utili anche solo per una prima e sommaria raccolta di informazioni.


Se tuttavia non si ha la certezza assoluta ed inopinabile della presenza di un errore di programmazione, può comunque essere utile aprire un report per dialogare con i manutentori del pacchetto interessato. In un mondo aperto come quello Open Source, difficilmente essi ignorano richieste d'aiuto e si rendono spesso disponibili a indirizzare gli utenti verso la possibile soluzione.

Occorre assicurarsi però di non aprire una segnalazione a riguardo di una questione già nota. Per non occupare inutilmente dello spazio, rischiare di perdere tempo e frammentare l'attività, risulta fondamentale evitare la creazione di ulteriori duplicati. Se, da un lato, le pagine dei bug comuni possono aiutare, molto più importante, quasi obbligatoria, è una ricerca mirata e preliminare all'interno di Bugzilla. Sono sufficienti i passaggi qui di seguito illustrati.


Raggiungere la home page di Bugzilla e selezionare il collegamento Search presente nell'header.

Per usare la ricerca semplice, occorre inserire del testo e opzionalmente filtrare per stato e prodotto. Anche se tale funzione può risultare fruttifera, spesso conviene tuttavia optare per un'esplorazione più fine tramite il motore offerto da “Advanced Search”.

Bugzilla – Ricerca semplice.


Ora è infatti possibile sfruttare impostazioni sicuramente più mirate come, per esempio, la scelta del componente. Va ricordato che l'utente può selezionare più elementi dalle liste, per personalizzare ulteriormente la richiesta. In seguito alla pressione del bottone “Search” e, dopo un breve lasso di tempo di attesa, il browser aggiornerà la pagina e mostrerà le segnalazioni più coerenti con i parametri impostati.


Ricerca per più componenti
In attesa...
Bugzilla – Ricerca avanzata.


Per consultare un report, è sufficiente cliccare sull'ID del bug, oppure sul valore della colonna “Summary”.


Bugzilla – Risultato ricerca.


A questo punto, l'utente – se autenticato nel sistema e se lo ritiene opportuno – può partecipare all'evoluzione della situazione con semplici interventi:

  • Può commentare o aggiungere allegati, se potenzialmente funzionali alla risoluzione della problematica.
  • Può aggiungere il proprio contatto alla cosidetta CC list (semplicemente spuntando l'apposita casella e invocando il bottone Save changes), in modo da ricevere notifiche via mail a riguardo del report interessato.


Bugzilla – Consultazione di un report.


Segnalazione di bug (tramite browser)

Il modo più semplice e rapido per aprire un report e segnalare un problema, è quello di affidarsi all'interfaccia web di Bugzilla. I passaggi sono sostanzialmente i seguenti.

Per prima cosa, occorre effettuare il login assicurandosi di possedere un profilo attivato mediante la procedura descritta nella sezione precedente della presente guida.


Login a Bugzilla.


Cominciare quindi la creazione della segnalazione tramite il click sul pulsante New, situato nell'header della pagina, in alto a sinistra. Va scelta la classificazione giusta, nel nostro caso Fedora.


Classificazione per il bug.


Ora, occorre selezionare il prodotto adatto. Se si sta per segnalare un problema tecnico derivante dall'utilizzo del sistema operativo, si deve optare per il prodotto Fedora. Diverso può essere, per esempio, il caso di un errore rilevato nelle note di rilascio, per il quale conviene scegliere Fedora Documentation.


Tipologia di prodotto a cui il bug si riferisce.


Il momento cruciale dell'intero processo è quello della stesura vera e propria del report. Bugzilla presenta un form con alcuni dati da compilare.

  1. Component: prodotto oggetto della segnalazione, il quale evidenzia il comportamento scorretto che è stato rilevato. Cominciando a scrivere, un menù a tendina compare per facilitare l'inserimento. Se l'utente non è pienamente sicuro a riguardo della natura dell'inconveniente, può comunque selezionare un elemento a parer suo coerente con il problema. Il componente può essere successivamente variato da membri di alcuni team del Fedora Project;
  2. Version: versione di Fedora sulla quale si riscontra la presenza del bug;
  3. Severity: grado di criticità del problema. Non è un valore obbligatorio, ma può esser utile per evidenziare le questioni più prioritarie. Attualmente, è possibile scegliere tra:
    1. Urgent: il bug rende l'intero sistema inusabile, oppure mina la sua sicurezza. È importante notare che una problematica riferibile soltanto a dell'hardware specifico - come ad esempio configurazioni particolari di schede video, ecc. - non è sufficientemente critica per essere etichettata come urgente;
    2. High: il bug rende il programma inusabile, o riguarda problemi di licenza;
    3. Medium: un vero e proprio bug che rende il programma – o parte di esso – più difficile da usare;
    4. Low: problematiche meno urgenti, quali sottigliezze grafiche oppure bug riscontrati tramite l'utilizzo di configurazioni inusuali;
  4. Hardware: architettura del proprio processore, desumibile invocando $ uname -m da un prompt del terminale;
  5. OS: la compilazione di questo campo, per report riguardanti Fedora, risulta di poca utilità effettiva. Può essere tranquillamente ignorato (alternativamente, è sufficiente selezionare 'Linux');
  6. Summary: titolo applicabile al report. Deve essere il più possibile preciso e conciso per facilitare le ricerche da parte di altri utenti di Bugzilla;
  7. Description: contenuto del messaggio allegato alla segnalazione. Bugzilla indica una traccia che, pur non essendo strettamente necessaria, conviene seguire per poter fornire importanti dettagli ai manutentori:
    1. Description of the problem: descrizione che deve fornire quante più informazioni possibili a riguardo del problema. In un certo senso, è l'estensione più prolissa e dettagliata del campo Summary;
    2. Version-release number of selected component: versione specifica dei pacchetti che causano l'inconveniente. Il comando $ rpm -qa | grep nomeprogramma può aiutare ad identificare i dati richiesti da tale paragrafo;
    3. How reproducible: frequenza con la quale si verifica il problema. Alcuni esempi:
      1. Happens every time: la problematica si manifesta sempre quando si crea la situazione indicata dal paragrafo 'Steps to reproduce';
      2. Happens sometimes, but not always: non è chiaro quale evento faccia scattare la problematica, che quindi appare manifestarsi occasionalmente;
      3. Haven't tried to reproduce it: l'utente non ha provato a ricreare la situazione problematica;
      4. Tried, but couldn't reproduce it: il bug si è manifestato una singola volta e non è facile da riprodurre;
  8. Steps to reproduce: sequenza di passi con la quale è possibile azionare gli eventi che innescano il comportamento scorretto del componente;
  9. Actual results: dettagli relativi all'effettiva manifestazione del problema (per esempio, crash, output errati, ecc.);
  10. Expected results: al contrario del precedente punto, in tale paragrafo occorre specificare i risultati attesi, in un certo senso immaginando che l'applicazione interessata non sia affetta dal bug che si sta segnalando;
  11. Additional information: eventuali informazioni non fondamentali, ma che possono comunque essere utili per il processo di risoluzione;
  12. Attachment: opzionalmente, sono facilmente allegabili file dal proprio computer per chiarificare la situazione;
  13. Add External Bug: se si è a conoscenza del fatto che il bug è stato segnalato su altre piattaforme all'infuori di Red Hat Bugzilla (quali potrebbero per esempio essere le pagine Github, il sito dell'upstream oppure report relativi ad altre distribuzioni), si possono agganciare tali link esterni al nuovo report.


Stesura del bug-report.


Segnalazione di bug (tramite gnome-abrt)

ABRT – ovvero Automatic Bug Report Tool – è un software di interesse fondamentale per il miglioramento della qualità del sistema operativo Fedora. Esso intercetta gran parte dei crash che possono verificarsi durante l'utilizzo, facilitando la predisposizione di informazioni tecniche per la compilazione di un bug report.

Preinstallato all'interno dell'edizione Workstation, gnome-abrt è un comodo frontend grafico perfettamente integrato con Gnome e con i diversi ambienti desktop della distribuzione. In questa sezione esamineremo i passaggi significativi per una corretta segnalazione, assumendo che l'utente abbia già un profilo Red Hat Bugzilla attivo.

Può capitare che, durante l'esecuzione, un programma incorra in un errore e che quest'ultimo sia catturato dallo strumento descritto in questo capitolo, generando una notifica. In Gnome 3.16, tali avvisi appaiono per qualche secondo centralmente - in corrispondenza del lato superiore dello spazio di lavoro – e vengono poi raggruppati all'interno del calendario.

Notifica di ABRT all'interno di Gnome
Testo notifica completo
Rilevazione crash da parte di ABRT elencata assieme alle altre notifiche di Gnome


Un semplice click sul tasto segnala – oppure sull'icona dell'apposita applicazione, contrassegnata da un'allarme – consente all'utente di raggiungere la schermata principale di ABRT.

Icona di gnome-abrt da Gnome Shell.
Dettagli di un problema rilevato da ABRT
Schermata principale di gnome-abrt


In seguito al primo avvio, conviene salvare le proprie credenziali per il login automatico su Bugzilla, per evitare di doverle scrivere ripetutamente. Per fare ciò, occorre navigare all'interno del menu di ABRT – su Gnome, accessibile selezionando l'icona presente nel pannello superiore – e scegliere l'elemento Preferenze. Nella scheda Eventi, è quindi possibile individuare la voce relativa alla piattaforma di Red Hat. È sufficiente completare la configurazione di base, inserendo Nome utente e Password.


Configurazione evento Bugzilla
Inserimento credenziali Bugzilla
Menù di ABRT


All'interno della schermata principale, il tasto blu Riporta, permette di costruire il report vero e proprio. In seguito all'azionamento di tale bottone, verranno raccolte tutte le informazioni, grazie anche ad un'eventuale installazione di pacchetti aggiuntivi per il debugging. Lo stack trace può essere inviato ai server di Fedora per permettere ai manutentori di disporre di più dati utili. Anche se una ricerca via browser all'interno di Bugzilla è sempre raccomandata, in questa fase, ABRT è potenzialmente in grado di riconoscere se un bug simile è già stato segnalato. In quest'ultimo caso, l'utente sarà aggiunto alla rispettiva CC list e riceverà novità via mail in caso di sviluppi futuri.


Problema già noto
ABRT analizza il problema
Invio dello stack trace


La descrizione dell'evento problematico è il fulcro dell'intero processo. Per una corretta stesura, si consiglia la lettura del capitolo precedente, relativo alle segnalazioni via web.


Testo della segnalazione


L'ultimo passaggio riguarda gli allegati. La scelta dipende sostanzialmente dalla caratteristica del componente; per esempio, in presenza di software di sistema, possono risultare utili variabili relativi all'ambiente. È sempre consigliabile optare almeno per core_backtrace, backtrace, comment e reason. È bene ricordare che, con un semplice click, si ha l'opportunità di rivedere il contenuto di tali file. In caso di dubbio, si consiglia di selezionare più elementi possibili, per evitare di tralasciare dettagli importanti.


Scelta degli allegati


In seguito alla conferma, ABRT provvederà all'apertura vera e propria del report all'interno di Red Hat Bugzilla ed evidenzierà all'utente il relativo codice identificativo, per una successiva consultazione tramite browser.

All'interno del sommario, è possibile reperire o modificare importanti dettagli, quali lo stato, l'assignee – ovvero la persona o il gruppo incaricati di risolvere la questione -, la versione di Fedora ecc. Nei giorni successivi alla segnalazione, converrà tenere monitorato il proprio indirizzo e-mail per poter rispondere prontamente alle eventuali richieste effettuate dai componenti del Fedora Project che interverranno.


Home Page di Bugzilla
Dettagli relativi al report
Descrizione del report


Flags relativi ad un bug-report

In seguito all'intervento del manutentore del pacchetto interessato dal report dell'utente, oppure di un membro qualificato del Fedora Project, è possibile che venga variato lo stato – flag – dell'intera segnalazione. Per una lista comprensiva, e per comprendere l'intero ciclo di vita di un bug, si consiglia la lettura della pagina BugStatusWorkflow. Di seguito, si riportano e descrivono le principali etichette che possono essere applicate:

  1. NEW: stato primitivo di un report, assegnato automaticamente dal sistema appena esso viene riportato da un utente;
  2. NEEDINFO: flag assegnato per sottolineare la richiesta di un addetto, indirizzata ad uno o più partecipanti alla segnalazione. Esso sta ad evidenziare il fatto che, per proseguire nello studio del caso, l'assignee - persona che lavora alla risoluzione - ha bisogno di informazioni specifiche da un utente o da un altro operatore;
  3. ASSIGNED: utile per i manutentori, può essere utilizzato per assegnare il bug ad uno specifico membro di un gruppo. Una segnalazione, per esempio, che involve un componente del desktop Plasma, può inizialmente essere assegnata al KDE SIG. Successivamente, tale team ha poi la facoltà di incaricare una sola figura per la risoluzione;
  4. MODIFIED: tale etichetta viene usata quando una patch è pronta ed è stata inserita nei sistemi utilizzati dai manutentori, ma non è ancora presente nel pacchetto interessato;
  5. VERIFIED: il bug ha un fix confermato, reso finalmente disponibile in una successiva versione del pacchetto di riferimento. Tale nuova edizione, sta per entrare a far parte di un repository di test di Fedora. Workaround non ufficiali o patch manuali non applicate al componente non sono degne di nota per considerare una segnalazione come "verified";
  6. ON_QA: il pacchetto aggiornato per sistemare la problematica riscontrata è stato inserito nel repository updates-testing. L'utente che ha segnalato il problema è invitato a provare l'aggiornamento e partecipare al processo di rilascio lasciando il proprio karma (commento, feedback) nel sistema Bodhi. Se la nuova versione riceverà un adeguato riscontro, oppure supererà un certo lasso di tempo senza evidenziare nuovi bug, allora essa verrà certificata come stabile;
  7. CLOSED: condizione applicabile ad un report chiuso perchè scartato oppure perchè risolto:
    1. CLOSED ERRATA: il bug è stato risolto e incluso in un nuovo pacchetto del repository updates. “Errata” va utilizzato per una Fedora “Branched” (una versione 'numerata', come Fedora 22, ossia non una Rawhide);
    2. CLOSED RAWHIDE: identica alla condizione precedente, ma in questo caso il nuovo pacchetto raggiungerà solamente i repository Rawhide;
    3. CLOSED NEXTRELEASE: utilizzata quando il bug è stato risolto, ma il nuovo pacchetto verrà incluso in una versione Fedora successiva a quella della segnalazione;
    4. CLOSED INSUFFICIENT_DATA: il report viene chiuso a causa della mancanza di dati fondamentali o dell'insufficiente partecipazione dell'utente che l'ha aperto;
    5. CLOSED NOTABUG: il problema viene chiuso perché non rappresenta un vero proprio difetto dal punto di vista software;
    6. CLOSED CANTFIX: utilizzata sopratutto quando il software che possiede il bug proviene da sorgenti esterne non fa parte dei repository di Fedora;
    7. CLOSED WONTFIX: tale etichetta viene applicata quando la versione di Fedora indicata nella segnalazione raggiunge l'End Of Life e non viene più mantenuta;
    8. CLOSED WORKSFORME: utilizzata dal manutentore del pacchetto interessato, viene scelta quando una risoluzione viene confermata unilateralmente;
    9. CLOSED CURRENTRELEASE: tale opzione viene indicata quando un bug viene scoperto all'interno della fase Alpha o Beta e risolto nel rilascio finale di Fedora;
    10. CLOSED UPSTREAM: usata dal manutentore del pacchetto quando ritiene che la problematica verrà risolta dall'upstream (ossia dal programmatore o dal gruppo che sviluppa il prodotto all'infuori di Fedora).