Bugs and feature requests/it

In other languages: български (bg) English (en) español (es) français (fr) italiano (it) 한국어 (ko) русский (ru) 中文（中国大陆） (zh-cn) [edit]

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.

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

Il Processo

Occorre davvero inviare un bug-report?

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

Non si presuma che anche ogni altro utente abbia lo stesso identico 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, osservato nella sua evoluzione senza il rischio di venir perso di vista, così come sarebbe nel rumore di fondo della mailing-list.

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).

Il flusso in Bugzilla

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.

La Cultura 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:

• How to Report Bugs Effectively
• General Bugzilla Etiquette
• bugzilla.redhat.com pointers

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.

I duplicati

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.

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 probelma.

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.

Se si ha qualche dubbio, su come determinare il componente appropriato, vedere i dettagli in BugZappers/CorrectComponent.

Dopo ...

• 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!

• 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 this page.

• 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.

• 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.

Command-line interface

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".

Things Every Bug Should Have

• 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.
• 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.

Tips by Type of Bug

Crashes

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. 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
• JavaStackTraces

Wedges, Seizures, and Panics

If the entire machine locks up, and complete error output recorded in logfiles or on the screen, try some of the suggestions for diagnosing machine lockups and kernel crashes and hangs.

Hardware-Specific Bugs

If you suspect your bug has something to do with the specific hardware you have, attach or include a link to your Smolt profile in the bug. You can dump it to /tmp/smoltprofile.txt with the command: smoltSendProfile -p > /tmp/smoltprofile.txt (But see Bug 575524.)

Run yum install smolt if you don't already have Smolt installed.

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).

Enhancement Requests

• When filing an enhancement request in Bugzilla, add the keyword FutureFeature to the report. Make sure you supply enough information and rationale for your enhancement requests to be considered.
• 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

We pay special attention to security-sensitive bugs. Read the Security Bugs page to understand the special process.

Graphical User Interfaces

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).

• 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 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

• SELinux
• Firefox
• Printing
• Anaconda (installer)
• Kernel (also see common kernel problems)
  • Sound (also see KernelBugTriage)
• Virtualization
• X.org
• Fonts
• OpenOffice.org
• DeviceKit
• Rhythmbox
• PulseAudio
• Dracut
• QEMU

Filing bugs for multiple releases

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.

Help Wanted

• The Fedora Bug Triaging team is actively soliciting new volunteers. If you are interested, Please see the BugZappers page.

• Quality Assurance also welcomes new volunteers; see QA.