Bugs and feature requests/it

From FedoraProject

< Bugs and feature requests(Difference between revisions)
Jump to: navigation, search
(Bug comuni in pacchetti d'uso comune)
 
(17 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
[https://bugzilla.redhat.com/bugzilla/index.cgi 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.
 
[https://bugzilla.redhat.com/bugzilla/index.cgi 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 aiuo su come compilare un bug-report di qualità, fornendo alcuni suggerimenti.  
+
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.  
  
 
{{Admon/tip |Commonly Reported Bugs|La pagina, [[Bugs/Common| Fedora common bugs]] spiega come risolvere alcuni problemi comuni di installazione, upgrade o di HW/SW, noti.}}
 
{{Admon/tip |Commonly Reported Bugs|La pagina, [[Bugs/Common| Fedora common bugs]] spiega come risolvere alcuni problemi comuni di installazione, upgrade o di HW/SW, noti.}}
  
==Il Processo ==
+
= L'universo Bugzilla =
  
=== Occorre davvero inviare una segnalazione ? ===
+
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:
 
+
Unless you see a problem already reported in Bugzilla, mentioned in the release notes or other formal documentation (see http://docs.fedoraproject.org/), acknowledged by developers on a mailing list, listed on the [[Bugs/Common|common bugs page]], or listed as a broken dependency in the daily Rawhide Report, you should file a bug. Don't assume that everyone else is also seeing the same problem you are; many bugs are specific to a particular hardware, configuration, or habits of use. Discussing a bug on IRC or the fedora-test-list mailing list can help you diagnose the exact source and co-ordinate with others experiencing the same issue, but it is not a sufficient way to report the bug. It must be reported to Bugzilla so the issue can be properly tracked and will not be lost among the noise of the mailing list.
+
 
+
A common practice is to file a bug first, then e-mail the list with a link to the bug report, asking for further assistance.  Many bugs are also filed with no e-mail to the mailing list, so be sure to search Bugzilla for your problem.
+
 
+
=== Il flusso in Bugzilla ===
+
 
+
An overview of the official workflow for Fedora bugs can be found [[BugZappers/BugStatusWorkFlow|here]]. This should help you understand the life cycle of a Fedora bug.
+
 
+
=== Si dia inizio alle danze! ===
+
 
+
If you are new to Fedora's Bugzilla, then the first step is to [https://bugzilla.redhat.com/bugzilla/createaccount.cgi register an account].  It's a quick process, so don't hesitate to get started right away.  For details about the account creation process, please consult the [https://bugzilla.redhat.com/docs/en/html/myaccount.html bugzilla documentation].
+
 
+
=== Understanding Bugzilla Culture ===
+
 
+
Understanding how other people are expecting you to use the system will improve the way your problem is presented, make others more receptive and more likely to fix your bug, and make the experience more pleasant for everyone.  If you have never used Bugzilla before or are new to filing bug reports, it may be helpful to read the following pages.
+
  
 +
* [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively]
 
* [https://bugzilla.mozilla.org/page.cgi?id=etiquette.html General Bugzilla Etiquette]
 
* [https://bugzilla.mozilla.org/page.cgi?id=etiquette.html General Bugzilla Etiquette]
* [http://www.redhat.com/magazine/020jun06/features/bugzilla/ bugzilla.redhat.com pointers] - describes the essential steps to follow for all bugs!
+
* [http://www.redhat.com/magazine/020jun06/features/bugzilla/ bugzilla.redhat.com pointers]
* [http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively] (general advice)
+
  
If a particular software package is heavily used, it is more likely that users will find bugs and/or suggest enhancements to it.  It does not mean that the software is more buggy.
+
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]] has a few technical notes that may help Bugzilla make more sense.
+
[[BugZappers/UnderstandingBugzilla]] contiene una serie di note tecniche che possono aiutare a chiarire il senso e il funzionamento di Bugzilla.
  
=== Search for Duplicates ===
+
== 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.   
  
Very common known bugs are listed at [[Bugs/Common]].
+
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 [[Bugs/Common|common bugs page]]
 +
* elencato come un problema di dipendenza, nel Rawhide Report, giornaliero
  
It's important to search Bugzilla to make sure your bug hasn't already been reported. The easiest way is to do a [https://bugzilla.redhat.com/query.cgi?format=specific keyword search].  Or you can use the [https://bugzilla.redhat.com/query.cgi Advanced Form]. Or you can use https://bugz.fedoraproject.org/packagename to look for specific bugs for a package (replace 'packagename' with the name of the package you are checking).
+
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.<BR> (Molti bug non vengono annunciati in mailing-ist, per cui conviene sempre cercare in Bugzilla).
  
It's not generally useful to file "I'm experiencing this bug, too" comments, unless there are specific details which might be helpful in tracking down the cause (e.g. you have more detailed debugging information, or a different hardware or software configuration which means a hardware-specific or configuration-specific bug is more widespread than previously thought).
+
== I doppioni: che ingombro!  ==
  
If you are experiencing the bug in a more recent version of Fedora than reported in the bug, this is useful to mention.
+
I bug [[Bugs/Common|più comuni]].
  
See [[BugZappers/FindingDuplicates]] for more details.
+
Per evitare di riportare un bug già individuato, è importante [https://bugzilla.redhat.com/query.cgi cercare] in Bugzilla, e controllare se il bug esiste già. Si può fare una ricerca per parola, [https://bugzilla.redhat.com/query.cgi?format=specific simple search], oppure usare l' [https://bugzilla.redhat.com/query.cgi 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).
  
=== Gather Helpful Information ===
+
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.)
  
See "Tips by type of bug" below for specific guidance.
+
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 [[BugZappers/FindingDuplicates|Trovare duplicati]].
  
It is always useful to check /var/log/messages (for everyone) and ~/.xsession-errors (for desktop users) to see if there are any errors or warnings related to your problem.  Some programs also have dedicated files or directories in /var/log which are worth checking.
 
  
=== Start Filing the Bug ===
+
== Il Processo: Dall'Account all'Assegnamento ==
  
You can [https://bugzilla.redhat.com/enter_bug.cgi enter a new bug here], or if you know what the package name is you can go to https://bugz.fedoraproject.org/packagename (replace 'packagename' with the name of the package) and click on 'Report a new bug against this package' link.  
+
Un bug in Fedora segue un suo ciclo di vita: per una panomarica, vedi [[BugZappers/BugStatusWorkFlow|flusso dei bug]] in Fedora.
  
Read the report template carefully and provide all the requested information, as best you can.
+
; E' molto semplice iniziare!
  
Please try to stick to clearly explaining the bug and all necessary information. Adding comments such as "this needs to be fixed immediately!" or "this is unacceptable!" is not a good idea: it's only likely to make the maintainers feel as if you are attacking them, and this doesn't help them to fix the problem.
+
Per accedere a Bugzilla, occorre avere un account: è un'operazione molto rapida, basta fornire solo un indirizzo e-mail valido.<BR> Quindi non esitare a [https://bugzilla.redhat.com/bugzilla/createaccount.cgi registrare un account]. Per conoscere i dettagli sul processo di creazione dell'account, puoi consultare la [https://bugzilla.redhat.com/docs/en/html/myaccount.html bugzilla documentation].
  
=== Finding the Right Component ===
+
; Dove raccogliere le Informazioni
  
When reporting a bug, it is helpful if you select the right Product, Version and Components. By doing so, you reach the developer/maintainer of the affected software package, which helps resolve the bugs faster. If you assign it to the wrong component, it can be reassigned to the correct one, so never skip filing a bug report just because you couldn't figure out which component to assign it to.
+
Per una breve guida, vedere la sezione in basso, [[#Tipi di Bug |Tipi di bug]].
  
See [[BugZappers/CorrectComponent]] for details on how to determine the correct component if you aren't sure.
+
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.
  
=== After Your Bug is Filed ===
+
; Inviare il bug-report
  
* Developers do not normally acknowledge bug reports or offer comments unless they have substantial feedback or require more information from you. It does not mean that your bug reports have not been valuable. Keep them coming!
+
Si può inviare un nuovo bug, partendo da crea [https://bugzilla.redhat.com/enter_bug.cgi 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'''".  
  
* After reporting a bug, you might get feedback from other users, or the developer may change the status and/or resolution of the bug report.  For an explanation of the various statuses and resolutions, see [[BugZappers/BugStatusWorkFlow|this page]].
+
Leggere attentamente il report, fornendo tutte le informazioni richieste.
  
* Please keep your report focused on the original issue that was reported. Adding discussions of slightly related (or even entirely unrelated) will only cause the report to become confused and difficult to follow. If you notice a different problem, or when the initial problem is fixed you notice another problem that it was hiding, please file a new report rather than appending comments to the first report.
+
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'',<BR> non forniscono '''informazione''' e non contribuiscono a risolvere il problema.  
  
* If you file a bug against a version of Fedora and it is not fixed or otherwise resolved before the version reaches its End of Life (EOL), someone will need to test a more recent version of Fedora to see if the bug persists, and update the Version field if so.  Otherwise, your bug will be closed.  You will get an e-mail notification if this is the case.  Many bugs are fixed or made obsolete when software is incorporated into new versions of Fedora from upstream programmers.  Older bugs remain in the system for future reference, but re-testing will keep the bug open and "on the radar" for Fedora developers.  See [[BugZappers/HouseKeeping]] for more process information.
+
; Assegnamento - Individuare il componente giusto
  
=== Command-line interface ===
+
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|BugZappers]]) si incaricheranno di inviarlo al destinatario giusto. 
  
If you need a command-line or programmatic interface to Bugzilla, try: "yum install python-bugzilla" and see the included documentation.  This provides the command "bugzilla".
+
=== Il corredo informativo essenziale di ogni Bug ===
  
== Things Every Bug Should Have ==
+
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.
  
* '''Version number''': The exact version number of the problem RPM (or a list of suspicious RPMs).  The number in the Version selector field is the version of the Fedora distribution as a whole (9, 10, Rawhide); the RPM version number for a specific component within the distribution will change as updates are released.
+
Ricordarsi sempre che ''spiegare ciò che '''è successo''' ≠ spiegare ciò che '''sarebbe dovuto succedere'''''.
* '''Clear description''': Reporting as much as possible about what was happening at the time of the incident, or exact steps about how to reproduce the bug.  Explanation of how what happened differs from what should happen, if it's not obvious.
+
* '''Diagnostic info''': Any relevant warnings printed on screen, excerpt from system logs around the time of the problem, any troubleshooting dumps available.
+
* '''Context''': For example, if this is a window manager problem, is it happening under GNOME or KDE?  If this is a network problem, what does the network setup look like?  If an application is being run in an unusual way (emulation, remotely), this should be mentioned.  What related items on the system have been customized?  Use your good judgment and common sense.
+
  
Additional information may be requested out of course, depending on the type of bug and affected component. See "Tips by Type of Bug" below.
+
Ulteriori informazioni, potrebbero essere richiesti, a seconda del tipo di bug e di componente interessato. Vedere la sezione [[#Tipi di Bug|Tipi di bug]], successiva.
  
== Tips by Type of Bug ==
+
Se si ha qualche dubbio, su come determinare il componente appropriato, vedere i dettagli in [[BugZappers/CorrectComponent|Correct Component]].
  
=== Crashes ===
+
{{Admon/note|
 +
Se il proprio bug è presente in più di una versione di Fedora, si può clonarlo cliccando su '''Clone This Bug''', nell'angolo in alto a destra del bug-report ed assegnarli una nuova versione.}}
  
If you have experienced a program crash, it will almost certainly be necessary to include a stack trace with your bug report.  Crashes are often difficult to reproduce and even more difficult to fix, so the more information you can provide, the better.
+
== E dopo? ==
You will probably need to install -debuginfo RPMs so your stack trace will have useful debugging symbols.  See the following pages for more information:
+
  
* [[StackTraces]]
+
* 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.   
* [[JavaStackTraces]]
+
  
=== Wedges, Seizures, and Panics ===
+
* 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, [[BugZappers/BugStatusWorkFlow|BugStatusWorkFlow]]. 
  
If the entire machine locks up, and complete error output recorded in logfiles or on the screen, try some of the suggestions for  [[Common_kernel_problems#Diagnosing_.22My_machine_locked_up.22|diagnosing machine lockups]] and [[Common_kernel_problems#Crashes.2FHangs|kernel crashes and hangs]].
+
* 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.
  
=== Hardware-Specific Bugs===
+
* 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 [[BugZappers/HouseKeeping|HouseKeeping]].
  
If you suspect your bug has something to do with the specific hardware you have, attach or include a link to your [https://fedorahosted.org/smolt/ Smolt] profile in the bug.  You can dump it to {{filename|/tmp/smoltprofile.txt}} with the command: {{command|smoltSendProfile -p > /tmp/smoltprofile.txt}} (But see [https://bugzilla.redhat.com/show_bug.cgi?id=575524 Bug 575524].)
+
{{Admon/note| Per gli smanettoni|
 +
Se occorre una CLI per Bugzilla, provare il programma '''python-bugzilla'''.}}
  
Run {{command|yum install smolt}} if you don't already have Smolt installed.
+
== Sensibili alla sicurezza ==
  
A strong indication of a hardware-specific bug is that other people with different hardware should be able to reproduce the bug, but can't. They also usually involve code that specifically interacts with a peripheral, such a webcam, video card, printer, or sound card (so for instance, it is uncommon for bugs affecting the user interface of a word processor or desktop calculator to be hardware-specific).
+
Noi, poniamo particolare attenzione ai bug inerenti alla sicurezza. Leggere la pagina [[Security/Bugs|Security Bugs]], per approfondire il particolare processo seguito.
  
=== Enhancement Requests ===
+
== Per suggerire nuove proposte ==
  
* When filing an enhancement request in Bugzilla, add the keyword '''Future<code></code>Feature''' to the report. Make sure you supply enough information and rationale for your enhancement requests to be considered.
+
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]].  
* The Fedora Project has the objective to be a platform built exclusively from free and open-source software. Suggestions to include support for proprietary or other legally encumbered software is not constructive. See the list of [[forbidden items]] page for details about this.
+
* If you want to make a new feature happen on your own create a wiki page for your feature and get it accepted.  See more on the Feature Process at [[Features/Policy]].
+
* Requests for new packages to be added to Fedora should not be added to Bugzilla.  Please add them to the wiki instead, on the [[Package maintainers wishlist]].
+
  
=== Security-Sensitive===
+
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 [[Features/Policy| Feature Policy]].
  
We pay special attention to security-sensitive bugsRead the [[Security/Bugs|  Security Bugs]] page to understand the special process.
+
La richiesta può essere inoltrata anche in Bugzilla, aggiungendo al report, contenente le informazioni, la dicitura '''Future<code></code>Feature'''.  
 +
   
 +
{{Admon/note|
 +
Le richieste per nuovi pacchetti non dovrebbero essere inviate in Bugzilla, ma in wiki, sulla pagina [[Package maintainers wishlist]].}}
  
===Graphical User Interfaces===
+
== Tipi di Bug ==
 +
{{Admon/note|
 +
A partire da Fedora 13, molti dei bug quì trattai sono automaticamente gestiti da abrt (Automatic Bug Reporting Tool), che estrae dal sistema in esecuzione le informazioni su runtime, stack trace, librerie coinvolte e quant'altro necessario. Tuttavia il programma ancora non è in grado di indicare anche le operazioni e le cause effettive che hanno creato il bug, quindi occorre completare il report con alcune informazioni.}}
  
If you are having trouble with a graphical user interface (GUI), it is often helpful to include a screenshot showing the bug in action.  This helps developers find the exact place in the code which is causing the bug, and helps communicate what is going wrong when it is difficult to reproduce (for example, machine-specific layout problems).
+
=== Bug comuni in pacchetti d'uso comune ===
 
+
* To take a screenshot, hit the "Print Screen" button on your keyboard, or in from the GNOME menu select: Applications -> Accessories -> Take Screenshot
+
 
+
* To get video of your screen (a "screencast"), you can use [http://live.gnome.org/Istanbul Istanbul].  "yum install istanbul" on the command line, then run "istanbul".  It will also appear on the GNOME menu under: Applications -> Sound & Video -> Istanbul Desktop Session Recorder
+
 
+
=== Information required for bugs in specific components ===
+
  
 
* [[Bug_info_SELinux|SELinux]]
 
* [[Bug_info_SELinux|SELinux]]
Line 143: Line 139:
 
* [[:Category:Fonts and text QA|Fonts]]
 
* [[:Category:Fonts and text QA|Fonts]]
 
* [[Bug_info_openoffice|OpenOffice.org]]
 
* [[Bug_info_openoffice|OpenOffice.org]]
* [[Bug_info_DeviceKit|DeviceKit]]
 
 
* [[Bug info Rhythmbox|Rhythmbox]]
 
* [[Bug info Rhythmbox|Rhythmbox]]
 
* [[How to debug PulseAudio problems|PulseAudio]]
 
* [[How to debug PulseAudio problems|PulseAudio]]
Line 149: Line 144:
 
* [[Testing/qemu|QEMU]]
 
* [[Testing/qemu|QEMU]]
  
=== Filing bugs for multiple releases ===
+
=== 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, [[StackTraces|Stack Traces]] e [[JavaStackTraces|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 [https://fedorahosted.org/smolt/ Smolt], che possono essere ottenute in un file {{filename|/tmp/smoltprofile.txt}} con il comando
 +
smoltSendProfile -p > /tmp/smoltprofile.txt
 +
 
 +
(Ma a tal proposito, vedere [https://bugzilla.redhat.com/show_bug.cgi?id=575524 Bug 575524].)
 +
 
 +
Eseguire <code>yum install smolt</code>, o usare <code>gpk-application</code>, 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 <code>Stamp/Rsist</code> 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 [http://live.gnome.org/Istanbul Istanbul].<BR>
 +
Una volta installato, lanciare il programma, selezionando in Gnome, '''Applicazioni -> Audio & Video -> Istanbul Desktop Session Recorder'''.
 +
 
 +
=== Errori, Blocchi, e Panics ===
  
If your bug is present in more than one Fedora release, you can clone it by clicking ''Clone This Bug'' in the top-right corner of the bug report and then assign a different version number in the newly created report.
+
Se il sistema si blocca, ed errori vengono segnalati nei log file o sullo schermo, provare a vedere se i suggerimenti indicati in [[Common_kernel_problems#Diagnosing_.22My_machine_locked_up.22|diagnosing machine lockups]]  [[Common_kernel_problems#Crashes.2FHangs|kernel crashes and hangs]], possonon essere d'aiuto.
  
== Help Wanted ==
+
== Si cerca aiuto, sempre! ==
  
* The Fedora Bug Triaging team is actively soliciting new volunteers. If you are interested, Please see the [[BugZappers]] page.
+
* Il team Fedora Bug Triaging, è sempre alla ricerca di nuovi volontari. Se vuoi partecipare, vedi la pagina [[BugZappers]].
  
* Quality Assurance also welcomes new volunteers; see [[QA]].
+
* Il team Quality Assurance, anch'esso cerca nuovi volontari. Vedi [[QA]]
  
 
[[Category:Bugs]]
 
[[Category:Bugs]]
 
[[Category:Debugging]]
 
[[Category:Debugging]]

Latest revision as of 13:42, 20 March 2012

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.

Idea.png
Commonly Reported Bugs
La pagina, Fedora common bugs spiega come risolvere alcuni problemi comuni di installazione, upgrade o di HW/SW, noti.

Contents

[edit] 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.

[edit] 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).

[edit] 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.


[edit] 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.

[edit] 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.

Note.png
Se il proprio bug è presente in più di una versione di Fedora, si può clonarlo cliccando su Clone This Bug, nell'angolo in alto a destra del bug-report ed assegnarli una nuova versione.

[edit] 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.
Note.png
Per gli smanettoni
Se occorre una CLI per Bugzilla, provare il programma python-bugzilla.

[edit] Sensibili alla sicurezza

Noi, poniamo particolare attenzione ai bug inerenti alla sicurezza. Leggere la pagina Security Bugs, per approfondire il particolare processo seguito.

[edit] 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.

Note.png
Le richieste per nuovi pacchetti non dovrebbero essere inviate in Bugzilla, ma in wiki, sulla pagina Package maintainers wishlist.

[edit] Tipi di Bug

Note.png
A partire da Fedora 13, molti dei bug quì trattai sono automaticamente gestiti da abrt (Automatic Bug Reporting Tool), che estrae dal sistema in esecuzione le informazioni su runtime, stack trace, librerie coinvolte e quant'altro necessario. Tuttavia il programma ancora non è in grado di indicare anche le operazioni e le cause effettive che hanno creato il bug, quindi occorre completare il report con alcune informazioni.

[edit] Bug comuni in pacchetti d'uso comune

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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.

[edit] 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