No edit summary |
No edit summary |
||
| Line 67: | Line 67: | ||
Lisez attentivement le formulaire et fournissez toutes les informations requises du mieux que vous pouvez. | Lisez attentivement le formulaire et fournissez toutes les informations requises du mieux que vous pouvez. | ||
Essayez de vous attacher à expliquer clairement le bogue et toutes les informations nécessaires. Ajouter des commentaires du genre « cela doit être corrigé immédiatement » ou « ceci est inacceptable » n'es pas la meilleure idée : non seulement, les mainteneurs vont vraisemblablement se sentir attaqués, mais cela ne les aidera pas à régler le problème. | |||
=== Trouver le bon composant === | |||
Lors du signalement d'un bogue, il est important de sélectionner le bon produit, la bonne version et le bon composant. En faisant cela correctement, vous entrez en contact avec les développeurs/mainteneurs du paquet logiciel concerné, ce qui accélère la résolution du bogue. Si vous l'assignez au mauvais composant, il peut être ré-assigné par la suite au bon composant, c'est pourquoi, il ne faut pas vous arrêtez de rapporter un bogue si vous n'êtes pas capable d'identifier le composant auquel l'assigner. | |||
Reportez-vous à [[BugZappers/CorrectComponent]] (composant correct) pour savoir comment déterminer le bon composant si vous avez un doute. | |||
=== Après que votre bogue a été signalé === | |||
* | * Les développeurs n'accusent pas réception des rapports de bogue ou ne les commentent pas sauf s'ils ont un retour d'expérience substantiel ou s'ils ont besoin de plus d'informations de votre part. Ne pas recevoir d'accusé de réception, ne signifie pas que votre rapport n'a pas d'intérêt. Laissez faire les choses ! | ||
* | * Après avoir rapporté un bogue, vous pouvez avoir un retour d'autres utilisateurs, ou le développeur peut en changer le statut/état (Status) et/ou la raison de la clôture (Resolution). Reportez-vous à [[BugZappers/BugStatusWorkFlow|cette page]] pour des explications sur les différents statuts/états (Status) et les différentes raisons de clôture (resolutions) | ||
* | *Maintenez votre rapport focalisé sur son problème d'origine. Ajouter des commentaires en vague relation (ou sans relation du tout) avec ce problème d'origine ne peut qu'apporter de la confusion et le rendre difficile à suivre. Si vous détectez un problème différent, ou, après que le problème a été résolu, vous détectez un problème que le problème d'origine masquait, signalez un nouveau bogue plutôt que d'ajouter des commentaires au premier rapport. | ||
* Si vous signalez un bogue à propos d'une version de Fedora et que celui-ci n'est pas résolu avant que la version n'atteigne sa fin de vie (EOL), quelqu'un doit tester la version plus récente de Fedora pour voir si le bogue persiste et, le cas échéant, mettre à jour le champ « Version ». Autrement, votre bogue sera fermé. Dans un tel cas, vous recevrez une notification par courriel. Beaucoup de bogues sont résolus ou rendus obsolètes lorsque le logiciel est incorporé dans une nouvelle version de Fedora depuis l'amont. Les bogues anciens restent dans le système pour pouvoir s'y reporter ultérieurement, mais « re-testing » (test à nouveau) maintient le rapport de bogue ouvert et « dans le collimateur » des développeurs de Fedora. Consultez [[BugZappers/HouseKeeping]] pour une information complète sur le processus. | |||
=== Command-line interface === | === Command-line interface === | ||
Revision as of 07:20, 30 April 2016
Bugzilla est l'outil de suivi utilisé par le projet Fedora pour recevoir le retour des utilisateurs et des développeurs sur les bogues et les demandes d'amélioration de Fedora.
Parfois, certains rapports n'apportent pas toute l'information nécessaire, sont imprécis ou présentent d'autres défauts. Cela est un gâchis de temps. Les personnes qui rapportent les bogues perdent leur temps quand elles le font de manière vague, et les développeurs doivent passer plus de temps sur le bogue, ce qui est aussi une perte de temps ; dans certains cas, le bogue est même ignoré ou oublié. Cette page explique comment effectuer un rapport de bogue de qualité ou faire une suggestion d'amélioration de manière constructive.
La page Fedora common bugs est utile pour trouver des solutions à des problèmes déjà connus relatifs à l'installation, la mise à jour ou au matériel/logiciel.
Processus
Dois-je signaler un bogue ?
Sauf si le problème a déjà été signalé dans Bugzilla, mentionné dans les notes de version ou toute autre documentation formelle (see http://docs.fedoraproject.org/), reconnu par les développeurs sur une liste de diffusion, listé sur la page common bugs page, ou listé comme une dépendance brisée dans le rapport quotidien de Rawhide, vous devriez le signaler. Ne partez pas du principe que n'importe qui d'autre constate aussi le même problème : beaucoup de bogues sont spécifiques à un matériel particulier, une configuration ou des habitudes d'utilisation. Discuter du bogue sur IRC ou sur la liste de diffusion « test » de Fedora peut vous aider à diagnostiquer l'origine exacte et à vous coordonner avec d'autres utilisateurs rencontrant le même problème. Néanmoins, cela n'est pas une façon suffisante de signaler le bogue. Il doit faire l'objet d'un rapport sur Bugzilla pour pouvoir être suivi et ne pas se retrouver perdu dans le bruit de fond ambiant de la liste de diffusion.
Une pratique courante est de commencer par signaler le bogue, puis d'envoyer un courriel à la liste – avec un lien qui pointe sur le rapport de bogue — demandant de l'aide. Beaucoup de bogues sont signalés sans qu'un courriel ne soit envoyé à la liste, c'est pourquoi vous devez vérifier que votre bogue n'est pas déjà dans Bugzilla.
Le flux de travail de Bugzilla
Une vue d'ensemble du flux de travail pour les bogues de Fedora est disponible sur cette page. Cette dernière devrait vous aider à comprendre le cycle de vie d'un bogue chez Fedora.
Premiers pas
Si vous découvrez le Bugzilla de Fedora, alors la première chose à faire est de créer un compte. C'est un processus rapide, c'est pourquoi il ne faut pas hésiter à le faire dès maintenant. Pour des informations détaillées sur la création d'un compte, consultez la documentation de bugzilla.
Comprendre la culture Bugzilla
Comprendre à quelle genre d'utilisation de votre part les gens s'attendent devrait améliorer la façon dont vous allez présenter votre problème, rendre les autres plus réceptifs augmentant ainsi la probabilité qu'ils traitent le problème, et rendre l'expérience plus agréable pour tous. Si vous n'avez jamais utilisé Bugzilla auparavant et n'avez jamais signalé de bogue, la lecture des pages listées ci-dessous devrait vous aider.
- General Bugzilla Etiquette
- bugzilla.redhat.com pointers – décrit les principales étapes à suivre pour tous les types de bogues.
- How to Report Bugs Effectively (conseils généraux)
Si un paquet logiciel particulier est très utilisé, il est assez vraisemblable que les utilisateurs signalent des bogues ou proposent des améliorations pour lui. Cela ne signifie pas que ce paquet comporte plus de bogue que la moyenne.
BugZappers/UnderstandingBugzilla présente quelques notes techniques susceptible de mieux vous faire comprendre Bugzilla.
Rechercher des doublons
Les bogues très courants et connus font l'objet de la liste Bugs/Common.
Il est important de vérifier dans Bugzilla que votre bogue n'a pas déjà été rapporté. La manière la plus facile est de faire une recherche par mot clé (keyword search). Sinon, vous pouvez utiliser le formulaire avancé (Advanced Form) ou utiliser le nom du paquet ( https://bugz.fedoraproject.org/packagename ) pour rechercher les bogues spécifiques à un paquet (remplacez 'packagename' par le nom du paquet qui vous intéresse).
Il ne sert généralement à rien de rapporter des chose comme « Moi aussi je rencontre ce bogue » (I'm experiencing this bug, too), sauf s'il y a des détails qui pourraient servir à identifier la cause (p. ex. vous disposez d'informations de débogage plus détaillées, un matériel différent ou une configuration logicielle différente qui pourraient laisser penser qu'un bogue spécifique à un matériel ou à une configuration logicielle est plus répandu qu'on ne l'avait pensé initialement).
Si vous rencontrez le bogue dans une version plus récente de Fedora que ce qui est indiqué dans le rapport de bogue, il est utile de le signaler.
Reportez-vous à BugZappers/FindingDuplicates (trouver les doublons) pour plus de détails.
Rassembler les informations utiles
Voyez « Trucs par type de bogues » plus bas pour des conseils spécifiques.
Il est toujours utile de consulter /var/log/messages (pour tous) et ~/.xsession-errors (pour les utilisateurs de station de travail) pour y rechercher d'éventuels messages d'erreur ou avertissements relatifs à votre problème. Quelques programmes ont aussi des fichiers ou des dossiers dédiés dans /var/log qui valent la peine d'être consultés.
Commencer à rapporter le bogue
Sur la page d'accueil vous pouvez cliquer sur enter a new bug report (Signalez un nouveau bogue ici).
Ou, si vous connaissez le nom du paquet, pointer votre navigateur sur https://bugz.fedoraproject.org/packagename (en remplaçant 'packagename' par le nom du paquet). À partir de là, il y a deux manières de faire pour signaler le bogue :
- Cliquer sur le lien « Bugzilla » puis, dans la page de Bugzilla, cliquer sur le lien (tout en bas à gauche) « File a new bug in the packgage name component of the Fedora Product » (Signaler un nouveau bogue du nom du paquet composant dans le produit Fedora).
- Cliquer sur « Bugs » dans le menu de la page, puis dans la nouvelle page, cliquez sur l'icône intitulée « Open a new bug (Fedora) » (Ouvrir un nouveau bogue – Fedora).
Lisez attentivement le formulaire et fournissez toutes les informations requises du mieux que vous pouvez.
Essayez de vous attacher à expliquer clairement le bogue et toutes les informations nécessaires. Ajouter des commentaires du genre « cela doit être corrigé immédiatement » ou « ceci est inacceptable » n'es pas la meilleure idée : non seulement, les mainteneurs vont vraisemblablement se sentir attaqués, mais cela ne les aidera pas à régler le problème.
Trouver le bon composant
Lors du signalement d'un bogue, il est important de sélectionner le bon produit, la bonne version et le bon composant. En faisant cela correctement, vous entrez en contact avec les développeurs/mainteneurs du paquet logiciel concerné, ce qui accélère la résolution du bogue. Si vous l'assignez au mauvais composant, il peut être ré-assigné par la suite au bon composant, c'est pourquoi, il ne faut pas vous arrêtez de rapporter un bogue si vous n'êtes pas capable d'identifier le composant auquel l'assigner.
Reportez-vous à BugZappers/CorrectComponent (composant correct) pour savoir comment déterminer le bon composant si vous avez un doute.
Après que votre bogue a été signalé
- Les développeurs n'accusent pas réception des rapports de bogue ou ne les commentent pas sauf s'ils ont un retour d'expérience substantiel ou s'ils ont besoin de plus d'informations de votre part. Ne pas recevoir d'accusé de réception, ne signifie pas que votre rapport n'a pas d'intérêt. Laissez faire les choses !
- Après avoir rapporté un bogue, vous pouvez avoir un retour d'autres utilisateurs, ou le développeur peut en changer le statut/état (Status) et/ou la raison de la clôture (Resolution). Reportez-vous à cette page pour des explications sur les différents statuts/états (Status) et les différentes raisons de clôture (resolutions)
- Maintenez votre rapport focalisé sur son problème d'origine. Ajouter des commentaires en vague relation (ou sans relation du tout) avec ce problème d'origine ne peut qu'apporter de la confusion et le rendre difficile à suivre. Si vous détectez un problème différent, ou, après que le problème a été résolu, vous détectez un problème que le problème d'origine masquait, signalez un nouveau bogue plutôt que d'ajouter des commentaires au premier rapport.
- Si vous signalez un bogue à propos d'une version de Fedora et que celui-ci n'est pas résolu avant que la version n'atteigne sa fin de vie (EOL), quelqu'un doit tester la version plus récente de Fedora pour voir si le bogue persiste et, le cas échéant, mettre à jour le champ « Version ». Autrement, votre bogue sera fermé. Dans un tel cas, vous recevrez une notification par courriel. Beaucoup de bogues sont résolus ou rendus obsolètes lorsque le logiciel est incorporé dans une nouvelle version de Fedora depuis l'amont. Les bogues anciens restent dans le système pour pouvoir s'y reporter ultérieurement, mais « re-testing » (test à nouveau) maintient le rapport de bogue ouvert et « dans le collimateur » des développeurs de Fedora. Consultez BugZappers/HouseKeeping pour une information complète sur le processus.
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:
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
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).
If you suspect your bug has something to do with the specific hardware you have, it will be necessary to identify the hardware so targeted action can be taken.
PCI and PCI-E devices found by the kernel can be listed with "lspci".
USB devices found by the kernel can be listed with "lsusb".
You may also find mention of specific devices or drivers in your system logs (run "journalctl").
Enhancement Requests
- When filing an enhancement request in Bugzilla, add the keyword Future
Feature to the report. The Keyword should be added right after submitting the bug. You will see the Keyword input box then. 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 Reporting a Security Vulnerability page to understand the special process of opening a security bug.
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
- Rhythmbox
- PulseAudio
- Dracut
- QEMU
- Systemd
- Wayland
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.