La première règle est : rapportez autant d'informations que vous pouvez. Même s'il y a des informations inutiles les développeurs pourront facilement les éliminer. Au contraire, la situation est bien pire lorsqu'il n'y a pas assez d'informations pour découvrir ou reproduire le problème - dans ce cas, les développeurs devront perdre du temps à deviner et/ou demander des précisions à l'auteur du rapport de bug.
Il y a plein d'exemples de rapports de bugs totalement inutiles, du genre "Hé, le port de gnomebidule est cassé. J'utilise FreeBSD-X.Y. Corrigez svp." Inutile de dire que de tels rapports sont juste un gaspillage de votre temps, du temps du développeur concerné et de bande passante. Au strict minimum, le rapport doit inclure les informations suivantes :
La version exacte du système d'exploitation (habituellement le résultat de uname -a).
La liste de tous les paquetages installés sur votre système.
Votre environnement (le résultat de /usr/bin/env).
Si vous faites une compilation à partir des ports, la date approximative où vous avez mis à jour les ports.
Des informations spécifiques à chaque type d'erreur : le log complet de la compilation dans le cas où la compilation d'un port est cassé, le contenu de la pile dans le cas d'un core dump, une description détaillée du problème lorsque cela concerne une application, etc. Essayez de vous mettre à la place du développeur et, pour chaque cas particulier, évaluez quelles informations peuvent être nécessaires pour qu'il puisse trouver la source du problème. Ne pensez pas que les développeurs connaissent déjà tout du problème et qu'ils sont juste trop paresseux pour le corriger.
Par ailleurs, essayez de répondre aux questions suivantes :
Tenez vous prêt à répondre à des questions supplémentaires. Bien souvent, les développeurs ne peuvent résoudre un problème ou même en faire le diagnostique tout de suite. Donc, montrez vous compréhensif lorsqu'on vous demandera de fournir d'autres informations.
Si vous avez une solution ou un moyen de contourner le problème, mettez le également dans votre rapport, même si vous n'êtes pas certain que cette solution est correcte. Si elle ne l'est pas, elle peut tout de même donner au développeur des idées et lui faire gagner du temps.
Avant de rapporter un bug, ou même d'envoyer un message sur la liste, faites une recherche dans les archives de la liste de diffusion GNOME pour FreeBSD pour voir s'il n'a pas déjà été rapporté. La plupart des problèmes rapportés sur les listes de diffusion sont déjà connus et, en faisant une recherche, vous pouvez trouver la solution à votre problème beaucoup plus rapidement.
Une fois que vous êtes certain qu'il s'agit d'un problème nouveau, il y a plusieurs manières de rapporter un bug concernant GNOME sous FreeBSD : vous pouvez envoyer un rapport sur la liste de diffusion freebsd-gnome, remplir un rapport de problème avec le système de rapport de bug FreeBSD, envoyer votre rapport aux développeurs GNOME concernés via leur système de gestion de bug ou utiliser une combinaison de ces différentes méthodes.
Il est impossible de définir des règles qui vous indiqueront clairement dans tous les cas où envoyer votre rapport - utilisez votre bon sens. Voici cependant quelques principes généraux :
Si le problème est spécifique à FreeBSD et temporaire (e.g. un checksum incorrect, un patch qui échoue, une erreur de syntaxe dans le Makefile du port, etc.) alors envoyez le rapport à la liste de diffusion freebsd-gnome.
Si le problème est clairement non spécifique à FreeBSD et que vous n'avez pas de solution disponible alors envoyez le rapport directement aux développeurs du logiciel (pour la plupart des composants du noyau de GNOME cela signifie que vous devrez utiliser leur système de gestion de bug "Bugzilla").
Si le problème n'est pas spécifique à FreeBSD mais assez sérieux et que vous avez une solution disponible alors envoyez le rapport à la fois à FreeBSD et au système de gestion de bug des auteurs, de façon à ce que le port concerné soit corrigé et que les autres utilisateurs FreeBSD puissent béneficier de votre solution sans avoir à attendre la sortie d'une nouvelle version du logiciel.