Avant de rapporter un bogue/problème avec les versions release, passez en revue cette liste de contrôle :

1. Premièrement, vérifiez les correctifs et les notes à-propos de la release.
2. Ensuite, regardez s'il n'y a pas une nouvelle release disponible.
3. Finalement, vérifiez les changements de versions d'OpenBSD.

Si rien ne ressemble à votre problème, veuillez vous familiariser avec sendbug(1) avant de soumettre un rapport de bogue.

Si votre problème est avec l'arborescence des sources -current plutôt que -release ou -stable,

1. Testez le problème au moins deux fois, avec des sources mises à jour à intervalle de quelques jours.
2. Ne pas rapporter des problèmes de compilation de l'arborescence de sources, à moins qu'ils ne soient persistants. C'est presque toujours une erreur de votre part, ou ils sont mises à jour au moment où vous les remontez. Les personnes qui travaillent sur le projet font des make build au moins une fois par jour, et généralement plusieurs fois par jour pour les différentes architectures.
3. Rappelez-vous que les serveurs AnonCVS sont mis à jour quelques heures après l'arborescence des sources en cours.
4. Vérifiez les changements effectués entre les versions d'OpenBSD pour voir si le problème a été résolu.
5. Un grand soin est apporté lors de la création des snapshots. Parfois quelques erreurs sont faites, nous nous excusons pour cela. Lire et écrire aux listes de diffusion est plus approprié qu'envoyer un rapport de bogue.

Toujours fournir le plus d'informations possibles. Essayez de pointer le problème exact. Donnez des instructions claires pour reproduire le problème. Essayez de le décrire avec autant de précision que possible et avec des mots ne portant pas à confusion, spécifiquement si le problème n'est pas facile à reproduire. Décrire les problèmes en disant “Cela crashe” ou “J'ai un problème étrange avec cette construction” est inutile. Communiquez avec les autres (sur les listes de diffusion ou sur tout forum où des utilisateurs compétents se rassemblent) pour confirmer que le problème est nouveau et de préférence répété. SVP, essayez de vous assurer vous que ce ne soit pas un problème local par l'utilisation d'un matériel défectueux ou non supporté, ou par l'usage d'un logiciel ou d'une option de construction non supportée.

SVP, ne commencez pas à fixer des problèmes qui requiert un travail significatif à moins que vous ne soyez capable de les comprendre, spécialement durant les périodes de publication pendant lesquelles nous ne faisons aucun changement majeur de code. Si vous vous apprêtez à écrire des quantités importantes de code, mentionnez-le sur les listes de diffusion afin de vous assurer que personne d'autre ne travaille sur ce problème (cela économise les efforts).

Chaque rapport de bogue doit contenir les éléments suivants :

1. La séquence exacte des étapes depuis le début est nécessaire pour reproduire le problème. Ceci devrait être autonome ; il ne suffit pas d'envoyer une simple commande sans les arguments et autres données que vous avez utilisées. Si le bogue requiert une séquence particulière d'événements, veuillez les lister. vous êtes encouragé à minimiser la taille de votre exemple, bien que cela ne soit pas absolument nécessaire. Si le bogue est reproductible, nous le trouverons de toute manière.
2. La sortie que vous obtenez. SVP, ne dites pas “cela ne fonctionne pas” ou “c'est en échec”. S'il y a un message d'erreur, montrez-le, même si vous ne le comprenez pas. Si OpenBSD panique avec une erreur particulière, restituez-la. Si rien ne se passe, dites-le. Même si le résultat de votre test restitue un problème ou tout autre comportement aberrant, il se peut qu'il ne se passe rien durant nos tests. La chose la plus facile à faire est de copier la sortie depuis le terminal, si possible.
   Note : Dans le cas d'erreurs fatales, le message d'erreur peut ne pas contenir toutes les informations disponibles. Dans ce cas, regardez aussi la sortie des journaux systèmes tels que ceux enregistrés dans /var/log. De plus, si vous utilisez une application qui a ses propres fichiers journaux, tel que httpd, vérifiez les erreurs que peuvent renfermer ses logs.
3. La sortie du noyau OpenBSD. Vous pouvez l'obtenir avec la commande dmesg, mais il est possible que la sortie de dmesg ne contienne pas toutes les informations capturées dans /var/run/dmesg.boot. Dans ce cas, incluez les informations des deux. Veuillez inclure cela dans tous les rapports de bogue.
4. Si vous utilisez un logiciel tiers relatif à votre bogue, dites-le, en incluant la version. Si vous parlez d'un snapshot, mentionnez-le, incluant ses dates et heures.
5. Une trace de votre kernel panic. Si votre noyau panique et que vous avez l'invite ddb(4), veuillez fournir le message d'erreur, aussi bien que les sorties des commandes trace et ps dans votre rapport de bogue telles que retournées. Si le machine se bloque, essayez d'activer sysctl ddb.console=1 et d'obtenir dans DDB via Ctl+Alt+Esc (en-dehors de X), ou d'envoyer BREAK si vous utilisez une console série. Si, pour une raison quelconque, le message panic n'est pas visible, vous pouvez l'obtenir à nouveau avec la commande show panic. Ceci est essentiel chaque fois que possible. Les rapports de panic sans message panic, ni retour des sorties trace et ps sont inutiles. La sortie des show registers pourrait être aussi intéressante. Vous pouvez ensuite redémarrer avec boot dump afin que l'image du noyau soit sauvé par savecore(8) pour un débogage post-mortem ultérieur, tel que décrit dans la page de manuel crash(8).
6. Si vous rapportez un problème avec le Système X Window sur une architecture qui utilise le serveur X.org, veuillez inclure le fichier complet /var/log/Xorg.0.log dans votre rapport en complément de l'information de dmesg.boot.

Ne soyez pas effrayé que votre rapport devient assez long. C'est un fait. Il est préférable de rapporter chaque chose dès la première fois plutôt que d'avoir à vous soutirer les informations. D'autre part, si vos fichiers d'entrées sont énormes, il vaut mieux demander en premier si quelqu'un est intéressé à les voir.

Si possible, utilisez la commande sendbug(1) pour aider à générer votre rapport de bogue. Il inclura automatiquement quelques informations utiles à-propos de votre matériel ce qui aide à diagnostiquer beaucoup de problèmes. Cet outil requiert que votre système puisse proprement envoyer un courriel. Si vous ne pouvez utiliser sendbug sur une machine OpenBSD fonctionnelle, veuillez envoyer votre rapport de bogue à bugs@openbsd.org.

Peut-être voulez vous envoyer une demande de fonctionnalité, pas nécessairement un bogue. Les nouvelles fonctionnalités sont acceptées, spécialement avec le code qui implémente votre nouvelle fonctionnalité suggérée.

Pour déboguer quelques problèmes, nous devons avoir le matériel sur lequel survient le problème. N'oubliez pas que les ressources du projet OpenBSD sont limitées. Vous pouvez donner quelques matériels.

Cette page est la traduction officieuse de la page “Problem Reports” officielle d'OpenBSD.
En cas de doute, merci de vous y référer !

Si vous voulez participer à l'effort de traduction, merci de lire ce topic.

Contribut(rice|eur)s :