Rendez-vous sur Arrakis

C'est lorsque nous croyons savoir quelque chose qu'il faut justement réfléchir un peu plus profondément. F. Herbert

Voici une traduction revue et corrigée par Raphaël Hertzog de son article. Vous trouverez l'original à cette adresse

Sept astuces pour rapporter les bugs Debian efficacement, et voir vos problèmes résolus

Remplir des rapports de bogue constitue la façon la plus courante de contribuer pour les utilisateurs. Bien que cela ne soit pas très difficile, je (Raphaël Hertzog) vais vous donner quelques conseils pour améliorer la qualité de vos rapports. Après tout, lorsque vous prenez du temps pour rapporter un bogue, c'est dans l'espoir de le voir résolu… Alors voyons comment mettre le plus de chances de votre côté.

1. Essayez de reproduire le bug

Si vous ne pouvez pas reproduire le bogue, il sera alors impossible de trouver sa cause d'origine, et par conséquent de le résoudre. Dans ce cas, je vous suggère d'attendre jusqu'à ce que vous ayez rencontré ce bug plusieurs fois. Vous trouverez peut-être ce qui le provoque (ou ce qui semble favoriser son apparition). Si l'application a un mode debug/verbose, ce serait une bonne idée de l'activer jusqu'à ce que le bug apparaisse une deuxième fois. Les logs générés seront très utiles au développeur pour comprendre ce qui s'est exactement passé.

Par conséquent, ne remplissez pas un rapport de bug tout de suite, à moins que vous puissiez le reproduire. L'exception à la règle, c'est lorsque l'application donne quelques informations telles qu'un core-dump, un back- trace ou un message d'erreur.

Bien entendu, si le bug apparaît lors d'une mise à jour, il est difficile de le reproduire (à moins de posséder plusieurs ordinateurs), mais vous devriez tout de même le rapporter. Assurez-vous d'y intégrer toutes les informations qui s'y rapportent (version des paquets avant et après la mise à jour logs de la mise à jour, etc).

2. Faîtes de votre mieux pour identifier le paquet mis en cause

Lorsque vous rapportez un bug à Debian, vous devez l'assigner à un paquet. Bien qu'il existe des pseudo-paquets utiles pour les problèmes ne se rapportant pas directement à un véritable paquet, dans la plupart des cas vous devrez rapporter le bug concernant le paquet particulier qui semble être la cause du problème rencontré.

De la même façon, vous devrez autant que possible attribuer le problème à un fichier (par exemple l'éxécutable de l'application buggée). À partir du moment où vous connaissez le nom du fichier, vous pouvez utiliser dpgk -S pour identifier le paquet correspondant.

$ dpkg -S /usr/bin/hamster-time-tracker
hamster-applet: /usr/bin/hamster-time-tracker

Notez que reportbug accepte pour paramètre un nom de fichier et fera la conversion ci-dessus à votre place.

Si vous ne connaissez que le nom de l'application (mais pas le nom du fichier de l'éxécutable associé), vous pouvez utiliser dpkg -S avec un motif afin qu'il retourne tous les résultats correspondants :

$ dpkg -S hamster
hamster-applet: /usr/share/applications/hamster-applet.desktop
hamster-applet: /usr/share/gnome/help/hamster-applet/es/statistics.page
[…]
hamster-applet: /usr/bin/hamster-time-tracker
[…]

Ou vous pouvez aussi vérifier dans la liste des paquets installés :

$ dpkg -l "*hamster*"
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom                       Version           Architecture      Description
+++-=========================-=================-=================-=======================================================
ii  hamster-applet            2.91.3+git2012051 all               time tracking applet for GNOME

3. Vérifiez que le bug n'est pas déja reporté ou résolu

Si une nouvelle version du logiciel est disponible, c'est une bonne idée d'essayer de reproduire le problème aussi avec cette dernière version. Étant donné que les développeurs ont tendance à se préoccuper uniquement de la dernière version, ils essaieront de le reproduire dans cette version, et risquent d'être agacés si le bug que vous rapportez est déja résolu. C'est pourquoi les rapports de bug des utilisateurs de testing/unstable ont tendance à être plus utile que les rapports des utilisateurs de la stable.

:Dans tous les cas, vous devrez vérifier que le bug n'a pas encore été rapporté créer un doublon est inutile et génère seulement plus de travail pour le développeur qui doit fusionner les deux bugs.

Notez que reportbug vous montrera automatiquement la liste des bugs ouverts avant de vous permettre d'en soumettre un nouveau.

4. Utilisez reportbug

Bien que le système de rapport de bogue Debian permette à quiconque de soumettre un nouveau bug avec un simple mail, vous devriez vraiment utiliser un programme fait pour ça tel que reportbug (ou reportbug- ng) car il incluera automatiquement de nombreuses informations utiles dans le rapport généré (version des dépendances, architecture actuelle, etc.) et vous assistera à chaque étape.

5. Décrivez le problème afin que le développeur puisse le reproduire

Idéalement, votre rapport devrait inclure tout ce qui est nécessaire au développeur pour reproduire le problème sur son système. Si un quelconque document provoque le bug, attachez-le au rapport.

Décrivez les étapes permettant de reproduire le bug avec autant de détails que si vous vouliez l'expliquer à votre grand-mère. Expliquez le comportement attendu du programme, et ce qui s'est passé à la place.

Vous pouvez en apprendre bien plus sur la façon d'écrire un bon rapport de bug dans cet article : How to report bugs effectively. C'est un peu long mais ça en vaut la peine si vous envisagez de rapporter des bugs, et donc d'interagir avec les développeurs.

6. Soyez sympa et prêt à aider

Lorsque vous remplissez un rapport de bug, gardez à l'esprit que vous êtes en train d'écrire à un développeur bénévole de logiciel libre, et non à un service consommateur. Vous devriez être respectueux et suivre les règles usuelles de courtoisie. Le temps disponible des développeurs est limité, et de devrait pas être gaspillé.

Soyez prêt à aider, car si un développeur commence à examiner votre problème, il peut avoir besoin d'informations supplémentaires (en particulier s'il ne peut le reproduire), et vous devriez être prêt à lui fournir. C'est pourquoi il est important de garder tout ce dont vous avez besoin pour reproduire le problème.

Dans certains cas, le mainteneur Debian peut être surchargé de travail. Vous pouvez offrir votre aide en transférant le bug au traqueur de bug amont.(Voir Upstream bug tracker) Ce sera toujours apprécié. Si vous êtes à peu près certain que le problème n'est pas spécifique à Debian, vous pouvez faire ça directement et définir l'URL du rapport de bug amont dans le champ “transféré” (par exemple avec bts forwarded <bug> <url>).

7. Utilisez le niveau de gravité convenable

Le système de suivi de bug Debian vous permet de définir la gravité initiale du rapport de bug (en ordre décroissant de gravité : critical, grave, serious, important, normal, minor, wishlist). Choisissez la gravité convenable selon les définitions officielles et ne les interprétez pas de travers.

En particulier, n'exagérez pas la gravité : par exemple, si vous avez perdu des données à cause d'une mauvaise utilisation du logiciel, il ne s'agit pas d'une séverité “critical” (i.e. "rm -rf *" n'est pas un bug critique de rm). Si vous utilisez seulement une petite partie d'un logiciel, et que cette partie ne fonctionne pas, le paquet peut être inutilisable pour vous, mais pas pour tout le monde. Il ne s'agit donc pas d'une gravité “grave”. La gravité “important” est la plupart du temps un bon choix dans ce cas.

Ne sous-estimez pas non plus la gravité, si un problème est suffisamment important pour devoir être réparé avec la prochaine version stable (par exemple une régression par rapport à la version précédente), choisissez alors une gravité de niveau release-critical (i.e au moins “serious”). Le mainteneur et le gestionnaire de version peut toujours abaisser le niveau de gravité s'il n'est pas en accord avec votre jugement initial.

Et maintenant, lancez-vous à coeur joie dans la soumission de bogues ! Vous pouvez vous référer à cet article via cette URL raccourcie : http://raphaelhertzog.com/go/bugreporting/

Notes de traduction

Voici ici un petit glossaire des éléments que je n'ai pas traduits en français afin d'éviter une déformation du sens de l'article, dans la mesure du possible.

log

Les logs sont les messages qu'un programme retourne, le plus souvent dans la console. De façon générale, ils sont les témoins de l'activité d'un programme. Afin de récupérer les logs, il est donc conseillé de lancer une application via une console.

Plus d'infos sur wikipedia : http://fr.wikipedia.org/wiki/Historique_(informatique)

core-dump

Fichier contenant la copie du contenu de la mémoire au moment du crash du programme.

back-trace

Trace des fonctions appelées par un programme, affichées pour le débugger. Les scripts python affichent une back-trace lorsqu'ils échouent avec une exception par exemple.

L'outil de débogage (gdb) est souvent utilisé pour générer une backtrace d'un programme C au moment d'une erreur (type segfault).

Plus d'infos : http://fr.wikipedia.org/wiki/D%C3%A9bogueur

Upstream bug tracker

Il s'agit du système de rapport de bug, non plus de debian, mais du logiciel lui-même. Ce sera donc les développeurs du logiciel qui essaieront de résoudre le problème, et non le développeur debian.

Par exemple, si un bug apparaît dans le noyau linux, le bug peut être rapporté au système de rapport de bug correspondant : https://bugzilla.kernel.org/

Forwarded field

Lorsque le champ est défini c'est que le problème a été soumis à l'auteur amont via le rapport dont l'URL est indiquée. La notion de “forward” donc “transfert” vient simplement du fait que le lieu d'échange privilégié pour résoudre ce problème a été déplacé dans le système de suivi de bogues du développeur amont.

Niveau de gravité

severity

Cela décrit la gravité d'un bug. Elle peut être

critical, grave, serious, important, normal, minor, wishlist

soit

critique, grave, sérieux, important, normal, mineur, souhait