Comment rapporter un bogue

Rapports de bogue sur les versions "Release"

1. Tout d'abord, vérifiez les patches et notes concernant les révisions.
2. Ensuite, cherchez s'il y a une révision plus récente disponible.
3. Enfin, vérifiez les changements opérés entre les versions d'OpenBSD.

Si rien ne semble correspondre à votre problème, nous vous prions de faire connaissance avec sendbug(1) avant la soumission d'un rapport de bogue.

Lisez ensuite les types de rapports de bogue souhaités.

Rapports de bogue sur la version "Current"

1. Testez le problème au moins à deux reprises, avec des sources mises à jour récemment.
2. Ne rapportez pas de problème de compilation de l'arbre des sources, sauf s'il demeure. Ils sont très souvent de votre faute, ou sont en cours de résolution lorsque vous les rencontrez. Les personnes travaillant sur le projet font des make build au moins une fois par jour, et même souvent plusieurs fois par jour sur des architectures différentes.
3. Rappelez-vous que les serveurs anoncvs sont mis à jour de manière significative sur l'arbre des sources actuel.
4. Vérifiez les changements réalisés entre les versions d'OpenBSD afin de savoir si le problème a été répertorié.
5. La création de snapshots est réalisée avec beaucoup de soin. Des erreurs sont parfois commises, et nos excuses s'y appliquent. Lire et écrire sur les listes de diffusion est dans ce cas plus approprié que l'envoi d'un rapport de bogue.

Comment créer un rapport de bogue

Nous vous prions de ne pas commencer à corriger les problèmes qui requièrent un travail conséquent tant que vous n'êtes pas certain de les comprendre, et spécialement pendant les périodes de révision lorsque nous ne devons pas faire de changement majeur sur le code. Si vous vous apprêtez à écrire de grandes portions de code, vérifier sur différents forums que personne ne travaille déjà sur ceci (évitant ainsi de multiples efforts).

Les éléments suivants devraient être présent dans tout rapport de bogue :

1. La succession exacte des étapes depuis le démarrage pour reproduire le problème. Ceci devrait être d'un seul bloc; envoyer une commande quelconque sans les arguments et données que vous lui avez passé n'est pas suffisant. Si un bogue requiert une suite particulière d'événements, nous vous prions de les lister. Vous êtes encouragés à minimiser la taille de votre exemple, mais ce n'est pas systématiquement nécessaire. Si le bogue est reproductible, nous le trouverons d'une manière ou d'une autre.

2. La sortie que vous obtenez. Nous vous prions de ne pas dire que cela "ne marche pas" ou "échoue". S'il y a un message d'erreur, montrez le, même si vous ne le comprenez pas. Si OpenBSD panique lors d'une erreur particulière, dites nous laquelle. Si rien ne se passe plus, dites-le nous également. Même si le résultat de votre situation de test est un plantage d'un programme ou toute autre chose évidente, cela ne devrait pas se produire lors de votre test. Le moyen le plus simple est de copier la sortie de votre terminal si cela possible.

   Note: dans le cas d'erreurs fatales, le message d'erreur fournit ne contiendra certainement pas toutes les informations disponibles. Dans ce cas, regardez également la sortie dans les journaux du système, comme ceux qui sont stockés dans /var/log. Ainsi, si vous traitez avec une application n'ayant pas son propre journal, comme httpd, vérifiez la présence d'erreurs à l'endroit ou elle garde ses journaux (en l'occurrence, /var/www/logs pour httpd).

3. La sortie du noyau OpenBSD. Vous pouvez l'obtenir avec la commande dmesg, mais il est possible que votre sortie dmesg ne contienne pas toutes les informations capturées dans /var/run/dmesg.boot. Si c'est le cas, proposez l'information venant de ces deux sources. Nous vous prions d'inclure ceci dans tout rapport de bogue.

4. Si vous utilisez en parallèle un logiciel tiers en rapport avec votre bogue, dites le, en incluant toute sous-version que le logiciel pourrait avoir. Si vous parlez d'un snapshot CVS ou FTP, mentionnez-le, en incluant la date et l'heure.

5. Un "traceback" de la panique du noyau. Si votre noyau a paniqué, et que vous êtes au prompt ddb>, nous vous prions de fournir le message, aussi bien que la sortie des commandes trace et ps dans votre rapport de bogue. Si la machine bloque, essayez d'activer sysctl ddb.console=1 avant le blocage et se retrouver dans DDB via la combinaison Ctl+Alt+Esc du clavier (en dehors de X) ou en envoyant BREAK si vous utilisez une console série.
   Si, pour une raison quelconque, le message de panique n'est pas visible, vous pouvez y avoir à nouveau accès via la commande show panic.
   Ceci est essentiel chaque fois que c'est possible. Les rapports de panique sans message de panique, rendent les sorties de traceback et de ps inutiles.
   La sortie de show registers pourrait être intéressante au possible. Vous pourriez alors vouloir redémarrer avec boot dump pour que l'image du noyau soit sauvegardée par savecore(8) pour un deboggage post-mortem comme décrit dans la page de manuel crash(8).

6. Si vous rapportez un problème en rapport avec le système X Window sur une architecture qui utilise le serveur X.Org, nous vous prions d'inclure le fichier /var/log/Xorg.0.log intégralement dans votre rapport, en plus de l'information dmesg.boot.

Ne soyez pas effrayé si votre rapport de bogue devient progressivement meilleur. Cela fait partie de la vie. Il est mieux de tout rapporter la première fois plutôt que nous ayons à vous tirer les vers du nez. D'un autre côté, si vos fichiers en entrée sont importants, il est plus que préférable de demander auparavant si quelqu'un aimerait y jeter un coup d'½il.

Envoi de rapports de bogue

Si cela est possible, utilisez la commande sendbug(1) afin d'intégrer le bogue dans notre système de suivis. Sendbug requiert que votre système puisse envoyer correctement des emails Internet. Si vous ne pouvez pas utiliser sendbug sur une machine OpenBSD fonctionnelle, envoyez s'il vous plaît votre rapport de bogue à bugs@openbsd.org.

Il se peut que ce que vous envoyez soit une demande de fonctionnalité, et pas nécessairement un bogue. Les nouvelles fonctionnalités sont acceptées, spécialement avec du code implémentant votre suggestion de fonctionnalité. Si quelqu'un d'autre écrit le code pour votre nouvelle fonctionnalité, il y a des chances que cela soit mal compris et créé de telle façon que cela ne vous convienne pas totalement.

Pour le débogage de certains problèmes, nous pourrions avoir à posséder le matériel qui a le problème. Nous vous prions de ne pas oublier que les ressources du projet OpenBSD sont limitées. Vous pouvez faire une donation de matériel.

Types de rapports de bogue par ordre de préférence :

1. Les problèmes reproductibles avec corrections des sources sont les plus appréciés.
2. Les problèmes qui ne sont pas spécifiques à votre disposition matérielle/logicielle.
3. Les problèmes reproductibles spécifiques à votre disposition logicielle.
4. Les problèmes reproductibles spécifiques à votre disposition matérielle.
5. Les problèmes non reproductibles -- ou les problèmes que vous n'aimeriez pas voir se répéter.