Bugzilla è il principale canale di comunicazione usato dal Fedora Project per ricevere feedback, da utenti e sviluppatori sui bug e le relative proposte di soluzione.
Spesso, alcune segnalazioni sono prive di informazione, inaccurate o inesatte, e tutto ciò consuma tempo prezioso, alla persona che ha riportato il problema, ed allo sviluppatore che è costretto a dedicare più tempo alla sua risoluzione, con il rischio magari che il bug venga trascurato o addirittura ignorato. Questa pagina vuole essere un aiuto su come compilare un bug-report di qualità, fornendo alcuni suggerimenti.
La pagina, Fedora common bugs spiega come risolvere alcuni problemi comuni di installazione, upgrade o di HW/SW, noti.
L'universo Bugzilla
Sapere come gli altri generalmente usano Bugzilla può servire a presentare meglio un probelma, a rendere gli altri più interessati a risolvere il proprio problema ed a rendere il servizio più piacevole per tutti. Se non si è mai usato Bugzilla, prima, o si è alla prima esperienza con l'invio di un bug-report, allora può essere d'aiuto leggere le seguenti pagine:
Se un particolare pacchetto ha una grande diffusione, è molto probabile che ci siano più utenti che segnalino bug e/o suggerimenti per il suo miglioramento, sneza che ciò significhi che il pacchetto sia più difettoso o pieno di bug, di altri, magari meno diffusi.
BugZappers/UnderstandingBugzilla contiene una serie di note tecniche che possono aiutare a chiarire il senso e il funzionamento di Bugzilla.
Occorre davvero inviare un bug-report?
Non si dia per scontato che sicuramente anche altri utenti avranno (?) lo stesso problema: molti bug sono causati da hardware specifici, configurazioni HW/SW particolari e da abitudini/operazioni dell'utente. Discutere il problema su IRC o in fedora-test mailing list, può aiutare a diagnosticare la causa del problema, ed a coordinarsi con altri utenti per la sua risoluzione, ma non basta per essere sicuri di aver segnalato il bug. Esso deve essere riportato in Bugzilla, solo così il problema può essere correttamente tracciato ed osservato nella sua evoluzione, senza il rischio di venir perso di vista, così come sarebbe nel rumore di fondo della mailing-list.
Generalmente, il bug va riportato nel caso in cui, non sia
- presente in Bugzilla
- menzionato nelle Release Notes o altro documento ufficiale (vedi http://docs.fedoraproject.org/),
- già in discussione in mailing-list
- elencato in common bugs page
- elencato come un problema di dipendenza, nel Rawhide Report, giornaliero
Una buona pratica dovrebbe essere quella di inviare prima un bug-report in Bugzilla, poi inviare in mailing-list, una richiesta di assistenza con un link al bug-report.
(Molti bug non vengono annunciati in mailing-ist, per cui conviene sempre cercare in Bugzilla).
I doppioni: che ingombro!
I bug più comuni.
Per evitare di riportare un bug già individuato, è importante cercare in Bugzilla, e controllare se il bug esiste già. Si può fare una ricerca per parola, simple search, oppure usare l' Advanced Search form. Si potrebbe anche usare https://bugz.fedoraproject.org/nome_pacchetto, per individuare i bug specifici di un pacchetto (sostituire nome_pacchetto, con il nome del pacchetto).
Solitamente, non è molto istruttivo fare commenti tipo "Anch'io ho riscontrato lo stesso tipo di problema", senza fornire i dettagli necessari da cui risalire alle eventuali cause (p.e. informazioni dettagliate di debug, l'HW impiegato, il tipo di configurazione SW che aiutano a capire il grado di estensione del bug.)
In un report già presente, diventa utile menzionare la comparsa del bug, se esso si verifica in una versione di Fedora, più recente.
Per maggiori dettagli sul problema dei duplicati, vedere Trovare duplicati.
Il Processo: Dall'Account all'Assegnamento
Un bug in Fedora segue un suo ciclo di vita: per una panomarica, vedi flusso dei bug in Fedora.
- E' molto semplice iniziare!
Per accedere a Bugzilla, occorre avere un account: è un'operazione molto rapida, basta fornire solo un indirizzo e-mail valido.
Quindi non esitare a registrare un account. Per conoscere i dettagli sul processo di creazione dell'account, puoi consultare la bugzilla documentation.
- Dove raccogliere le Informazioni
Per una breve guida, vedere la sezione in basso, Tipi di bug.
E' anche sempre utile controllare i file dei messaggi (/varlog/messages e ~/.xsession-errors), per vedere se esistono errori o avvisi legati al problema specifico. Alcuni programmi, hanno anche dei file e delle directory dedicate in /var/log, che è importante controllare.
- Inviare il bug-report
Si può inviare un nuovo bug, partendo da crea New bug, o se si conosce il nome_del_pacchetto, da https://bugz.fedoraproject.org/nome_del_pacchetto e cliccare sul link "Report a new bug against this package in Fedora or EPEL".
Leggere attentamente il report, fornendo tutte le informazioni richieste.
Si prega di limitarsi solo a spiegare il bug ed a fornire le necessarie informazioni: commenti tipo, occorre che sia risolto immediatamente, o questo è inaccettabile,
non forniscono informazione e non contribuiscono a risolvere il problema.
- Assegnamento - Individuare il componente giusto
Riportando un bug, è di valido aiuto, selezionare Product (p.e. Fedora), Version (p.e. 14) e Component (p.e. Anaconda), giusti, in modo da contattare direttamente lo sviluppatore/manutentore del pacchetto. Se non si sa a quale componente assegnare il pacchetto, completare comunque la segnalazione con le restanti informazioni disponibili, poichè il gruppo addetto allo smistamento dei pacchetti (i BugZappers) si incaricheranno di inviarlo al destinatario giusto.
Il corredo informativo essenziale di ogni Bug
Gli elementi essenziali che ogni bug deve possedere, così come presenti in Bugzilla, sono:
- Component: E' il nome del pacchetto che presenta il problema
- Version: E' la versione della distribuzione Fedora, nella quale si è verificato il problema.
- Summary: Un titolo indicativo del tipo di problema
- Description Riportare quante più indicazioni possibili, in occasione dell'occorrenza del problema
- Description of problem: Fornire una descrizione di ciò che è accaduto e delle operazioni che si stavano eseguendo, indicandone il contesto: se si ritiene sia un problema del gestore video, che ambiente desktop si stava usando? Se sia un problema di rete, quali erano le impostazioni di rete? Se un'applicazione viene fatta eseguire in maniera inusuale (emulazione, da remoto), occorre che sia specificato. Quali proprietà del sistema sono state volontariamnete modificate? Usando il proprio buon senso e giudizio, non si trascuri nulla di rilevante.
- Version-Release number of selected component (if applicable): Fornire la versione del componente
- How reproducible: Provando a ricreare le stesse condizioni in cui si è verificato il problema, indicare se il problema si presenta più o meno casualmente oppure si presenta deterministicamente, ossia sempre.
- Steps to Reproduce: Indicare i passi per riprodurre il problema
- Actual results: Indicare gli effetti ottenuti
- Expected results: Indicare i risultati desiderati
- Additional info: Fornire ulteriori informazioni, p.e. avvisi comparsi sullo schermo, parti rilevanti estratte dai file di log.
Ricordarsi sempre che spiegare ciò che è successo ≠ spiegare ciò che sarebbe dovuto succedere.
Ulteriori informazioni, potrebbero essere richiesti, a seconda del tipo di bug e di componente interessato. Vedere la sezione Tipi di bug, successiva.
Se si ha qualche dubbio, su come determinare il componente appropriato, vedere i dettagli in Correct Component.
E dopo?
- Normalmente gli sviluppatori non rispondono alle segnalazioni o forniscono commenti, a meno che non ci sia un feedback sostanziale o per richiedere maggiori informazioni. Ora il proprio bug-report viene adeguatamente valutato.
- Dopo l'invio di un bug-report, altri utenti potrebbero richiedere feedback e lo stesso sviluppatore potrebbe cambiare lo status e/o lo stadio di risoluzione del bug. Per una spiegazione dei vari status e stadi di risoluzione, vedere la pagina, BugStatusWorkFlow.
- Si prega tenere le discussioni successive, sempre circoscritte nell'ambito del problema, in quanto l'aggiunta di argomenti non attinenti o marginali contribuisce a rendere il report confuso e difficle da seguire. Se nel corso della risoluzione, si nota un nuovo problema, o se una volta risolto, compare un problema completamente inaspettato, si prega di avviare un nuovo report.
- Se si invia un bug di una versione di Fedora, che non viene risolto prima della sua EOL (End Of Life), esso può venir testato nella versione di Fedora più recente e se esso persiste, la Version del bug-report viene aggiornata. In caso contrario (bug risolto), il bug viene chiuso ed in tal caso si riceve un avviso via e-mail. Molti bug sono risolti o diventano obsoleti quando il software viene incorporato in nuove versioni di Fedora. I vecchi bug invece continuano a rimanere in Bugzilla per riferimenti futuri. Per ulteriori informazioni sul processo, vedere HouseKeeping.
Se occorre una CLI per Bugzilla, provare il programma python-bugzilla.
Sensibili alla sicurezza
Noi, poniamo particolare attenzione ai bug inerenti alla sicurezza. Leggere la pagina Security Bugs, per approfondire il particolare processo seguito.
Per suggerire nuove proposte
Il Fedora Project ha l'obiettivo di essere una piattaforma basata esclusivamente su software free & open-source. Quindi i suggerimenti volti ad includere supporto per software proprietario o soggetto a brevetti non verranno presi in considerazione. Per maggiori informazioni al riguardo, vedere la pagina forbidden items.
La richiesta può essere avviata creando nel proprio spazio della wiki una pagina contenente la feature. Essa poi verrà analizzata ed approvata, secondo il processo indicato in Feature Policy.
La richiesta può essere inoltrata anche in Bugzilla, aggiungendo al report, contenente le informazioni, la dicitura FutureFeature.
Tipi di Bug
Bug comuni in pacchetti d'uso comune
- SELinux
- Firefox
- Printing
- Anaconda (installer)
- Kernel (also see common kernel problems)
- Sound (also see KernelBugTriage)
- Virtualization
- X.org
- Fonts
- OpenOffice.org
- Rhythmbox
- PulseAudio
- Dracut
- QEMU
Crash
Se si è verificato un crash nel programma, occorerà allegare al report uno stack trace. I crash sono spesso difficili da riprodurre e ancora peggio, difficili da risolvere, perciò più informazioni si riescono a raccogliere, più possibilità si hanno per una sua rapida risoluzione. In tali situazioni, l'installazione dei pacchetti *-debuginfo consente di creare degli stack trace completi di simboli di debug. Per maggiori informazioni, vedere, Stack Traces e Java Stack Traces.
Bug Hardware-Specifici
Se si ritiene che il bug sia dovuto al proprio particolare HW, allegare o includere un link al profilo generato da Smolt, che possono essere ottenute in un file /tmp/smoltprofile.txt con il comando
smoltSendProfile -p > /tmp/smoltprofile.txt
(Ma a tal proposito, vedere Bug 575524.)
Eseguire yum install smolt, o usare gpk-application, se Smolt non è installato.
Una forte indicazione che si tratta di un bug HW, si ha quando altri utenti con HW diverso non sono in grado di riprodurre il bug, ed il problema interessa soprattutto le periferiche, come webcam, schede video, stampanti o schede audio.
Problemi con GUI (Graphical User Interfaces)?
Se si hanno problemi con la GUI, per aiutare gli sviluppatori a trovare la locazione esatta nel codice che causa il problema, e per migliorare la comunicazione nel caso sia difficile riprodurre il problema (p.e. problemi di layout specifici della macchina), è molto utile allegare al bug-report una istantanea che mostra il bug in azione.
Per prendere una istantanea, premere il tasto Stamp/Rsist in alto a centro-destra della tastiera, ed attendere un paio di sceondi; oppure in Gnome, selezionare Applicazioni -> Accessori -> Prendi Istantanea.
Per prendere una videata o "screencast" si può usare l'applicazione Istanbul.
Una volta installato, lanciare il programma, selezionando in Gnome, Applicazioni -> Audio & Video -> Istanbul Desktop Session Recorder.
Errori, Blocchi, e Panics
Se il sistema si blocca, ed errori vengono segnalati nei log file o sullo schermo, provare a vedere se i suggerimenti indicati in diagnosing machine lockups kernel crashes and hangs, possonon essere d'aiuto.
Si cerca aiuto, sempre!
- Il team Fedora Bug Triaging, è sempre alla ricerca di nuovi volontari. Se vuoi partecipare, vedi la pagina BugZappers.
- Il team Quality Assurance, anch'esso cerca nuovi volontari. Vedi QA