Bugs and feature requests/fr

Remplir un rapport de bogue ou 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 bogues que la moyenne.

BugZappers/UnderstandingBugzilla présente quelques notes techniques susceptibles 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 choses comme « Moi aussi je rencontre ce bogue », 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 ).

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

Blocages, attaques et paniques

Si la machine toute entière se retrouve bloquée et que l'intégralité des messages d'erreur sont enregistrés ou affichés à l'écran, essayez quelques unes des suggestions diagnosing machine lockups (diagnostic des verrouillage de la machine et kernel crashes and hangs (plantages et blocages du noyau).

Bogues spécifiques au matériel

Une indication assez claire de bogue lié au matériel est que d'autres personnes disposant d'un matériel différent ne peuvent reproduire le bogue alors qu'elles le devraient. Ordinairement ils n'impliquent que du code qui interagit avec un périphérique comme une webcam, une carte vidéo, une imprimante ou une carte son (il est donc rare qu'un bogue affectant l'interface utilisateur d'un traitement de texte ou une calculatrice soit spécifique au matériel).

Si vous suspectez que votre bogue est lié au matériel, il est nécessaire d'identifier ce matériel pour que des actions ciblées puissent être conduites.

Les périphériques PCI et PCI-E trouvés par le noyau peuvent être listés avec la commande

lspci

Les périphériques USB trouvés par le noyau peuvent être listés avec la commande

lsusb

Vous devriez aussi mentionner les périphériques et les pilotes spécifiques qui apparaissent dans les journaux du système. Exécutez

journalctl

Demandes d'amélioration

• Lorsque vous remplissez une demande d'amélioration dans Bugzilla, ajoutez le mot clé When filing an enhancement request in Bugzilla, add the keyword FutureFeature (fonctionnalité à venir) au rapport. Le mot clé doit être ajouté juste après la soumission du rapport. Vous apercevrez le champ de saisie du mot clé à ce moment. Assurez-vous que vous avez fourni une information et une justification suffisantes pour que votre demande d'amélioration soit prise en compte.
• Le projet Fedora a l'objectif d'être une plateforme uniquement constituée de logiciels libres et open source. Les suggestions d'introduction de prise en charge de logiciels propriétaire ou autrement légalement contraints ne sont pas constructives. Reportez-vous à la page forbidden items pour en savoir plus.
• Si vous voulez voir une nouvelle fonctionnalité de votre part apparaître, créez une page de wiki pour elle et faites-la acceptée. Reportez-vous au processus des fonctionnalités sur la page Features/Policy.
• Les demandes d'ajout de nouveaux paquets à Fedora ne doivent pas être faites dans Bugzilla. Ajoutez-les plutôt sur la page Package maintainers wishlist (liste de vœux des mainteneurs de paquets) du wiki.

Bogue influant sur la sécurité

Nous accordons une attention particulière aux bogues influant sur la sécurité. Consultez la page Reporting a Security Vulnerability (Signaler une vulnérabilité de sécurité) pour comprendre le processus spécial d'ouverture d'un bogue de sécurité.

Interfaces utilisateur graphiques

Si vous rencontrez des problèmes avec une interface utilisateur graphique (GUI), il est souvent utile de joindre une capture d'écran montrant l'effet du bogue. Cela aide les développeurs à localiser précisément l'endroit concerné dans le code et les aide à communiquer sur ce qui ne va pas lorsque c'est difficile de reproduire le bogue (p. ex. des problème d'agencement d'écran spécifiques à une machine).

• Pour prendre une capture d'écran, pressez la touche « Impr. Écran » de votre clavier, ou dans Gnome utilisez l'application « Capture d'écran ».

• Pour réaliser un enregistrement vidéo de votre écran, vous pouvez utiliser [1].

su -c 'dnf install recordmydesktop'

et utiliser

recordmydesktop

pour le lancer en ligne de commande.

Informations requises pour des bogues concernant des composants spécifiques

• 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

Signaler des bogues pour des versions multiples

Si votre bogue est présent dans plusieurs versions de Fedora, vous pouvez le cloner en cliquant sur "Clone this bug" dans l'angle supérieur gauche de l'écran et changer la version d'assignation dans le nouveau rapport.

Besoin d'assistance

• L'équipe de triage des bogues de Fedora recherche activement de nouveaux volontaires. Si cela vous intéresse, reportez-vous à la page BugZappers.

• L'équipe d'assurance qualité (QA) accueille aussi les nouveaux volontaires avec plaisir ; voir QA.