Bugs and feature requests/fr

Remplir un rapport de bogue et faire une demande d'amélioration

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

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.

Bogues couramment rapportés
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 « Choses à savoir 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 :

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

Interface en ligne de commande

Si vous avez besoin d'une interface en ligne de commande ou une interface de programmation avec Bugzilla, essayez

su -c 'dnf install python-bugzilla'

et consultez la documentation incluse. Ce paquet fournit la commande « Bugzilla ».

Éléments qui devraient accompagner un rapport de bogue

• Numéro de version (champ « Version »): Le numéro exact de version du paquets RPM (ou la liste des paquets RPM douteux). Le numéro dans la liste de sélection de la version est le numéro de version de la distribution de Fedora dans son ensemble (22, 23, Rawhide). Le numéro de version RPM pour un composant spécifique à l'intérieur de la distribution change au fur et à mesure de la parution des mises à jour.
• Une description claire (champ « Description »):en en disant le plus possible sur ce qui s'est passé au moment de l'incident ou sur les étapes à suivre pour reproduire le bogue. Expliquer également en quoi se qui s'est passé diffère de ce qui devrait se passer, si ce n'est pas quelque chose d'évident.
• Des informations de diagnostique: tous les avertissements pertinents affichés à l'écran, des extraits des journaux du système dans une période de temps englobant le problème, tous les « dumps » (instantanés de la mémoire) d'aide à la résolution de problème disponibles.
• Le contexte: par exemple, s'il s'agit d'un problème du gestionnaire d'affichage, cela se passe-t-il sous Gnome ou sous KDE ? Si c'est un problème de réseau, à quoi ressemble la configuration du réseau ? Si une application est exécutée d'une manière inhabituelle (émulation, à distance,…), cela doit être mentionné. Quels sont les items en relation avec le problème qui ont été personnalisés ? Servez-vous de votre jugement et de votre bon sens.

Des informations additionnelles peuvent bien sûr vous être demandées, selon le type de bogue et selon le composant concerné. Reportez-vous à « Choses à savoir par type de bogue » plus bas.

Choses à savoir par type de bogue

Plantages

Si vous rencontrez un plantage de programme, il est certainement nécessaire d'inclure une trace de pile – ou trace d'appels – dans votre rapport de bogue. Les plantages sont souvent difficiles à reproduire et même encore plus difficiles à résoudre, c'est pourquoi plus vous pouvez fournir d'informations, mieux c'est. Vous aurez probablement besoin d'installer -debuginfo RPM pour que votre trace de pile dispose de symboles de débogage utiles. Reportez-vous aux pages suivantes pour 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

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