POSSFR AnnexeD
De Framalang Wiki.
| Annexe C | | Annexe E |
Annexe D : Exemple d'instructions pour les rapports de bogues
Ceci est une version légèrement modifiée des instructions destinées aux nouveaux utilisateurs pour les rapports de bogues que l'on peut trouver sur le site du projet Subversion. Reportez-vous à la partie « Considérez tous les utilisateurs comme des volontaires potentiels » dans le Chapitre 8, Encadrer les volontaires pour plus de détails sur l'importance de telles instructions. Vous pouvez retrouver ce document dans sa version originale à l'adresse http://svn.collab.net/repos/svn/trunk/www/bugs.html.
Rapporter un bogue dans Subversion
Ce document vous indique comment et où rapporter les bogues (ce n'est pas une liste de bogues, vous pouvez la trouver ici par contre).
Où rapporter un bogue
- Si le bogue est dans Subversion lui-même, envoyez un e-mail à users@subversion.tigris.org. Une fois le bogue confirmé, quelqu'un, peut-être vous, peut l'inscrire dans le suivi des problèmes. (Ou, si vous êtes sûrs de vous, envoyez le directement à notre liste de développement : dev@subversion.tigris.org. Mais si vous n'êtes pas certain, il vaut mieux l'envoyer à users@ en premier, quelqu'un sera capable de vous dire si le comportement que vous avez rencontré est normal ou pas.)
- Si le bogue se trouve dans une librairie APR, rapportez-le s'il vous plaît à ces deux listes de diffusions : dev@apr.apache.org et dev@subversion.tigris.org.
- Si le bogue concerne la librairie Neon HTTP, rapportez-le s'il vous plaît à : neon@webdav.org et dev@subversion.tigris.org.
- Si le bogue est dans Apache HTTPD 2.0, rapportez-le s'il vous plaît à ces deux listes de diffusion : dev@httpd.apache.org et dev@subversion.tigris.org. La liste de diffusion Apache httpd génère beaucoup de trafic, il est donc possible que votre rapport de bogue passe inaperçu. Vous pouvez également enregistrer un rapport de bogue à l'adresse http://httpd.apache.org/bug_report.html.
- If the bug is in your rug, please give it a hug and keep it snug. [Si l'insecte (bug) est sous votre tapis, faites lui un gros câlin et gardez le bien au chaud]
Comment rapporter un bogue
Assurez vous déjà que c'est bien un bogue. Si Subversion ne réagit pas comme vous l'attendiez, vérifiez dans la documentation ou dans les archives des listes de diffusion des indices prouvant que c'est bien un comportement anormal. Bien sûr, si l'anomalie est évidente, par exemple si Subversion a détruit vos données ou fait fumer votre moniteur, vous pouvez vous fier à votre jugement. Mais en cas de doute n'hésitez pas à poser votre question en premier sur la liste de diffusion (users@subversion.tigris.org) ou sur IRC (irc.freenode.net) dans la canal #svn.
Quand vous êtes sûr et certain que c'est un bogue, le mieux est d'en faire une description simple et de présenter une méthode de reproduction. Par exemple, si la première fois que vous avez découvert le bogue, il affectait cinq fichiers sur dix commits essayez de le reproduire avec seulement un fichier et un commit. Plus la méthode de reproduction est simple, plus il y a de chance qu'un développeur arrive à le reproduire et le corrige.
Lorsque vous rédigez la méthode de reproduction, ne vous contentez pas d'écrire une prose décrivant ce que vous faisiez et ce qui a déclenché le bogue. Il vaut mieux retranscrire exactement la série de commandes utilisées et leurs résultats. Servez-vous du copier/coller. Si des fichiers sont impliqués, prenez bien soin d'ajouter leur nom, voire même leur contenu si vous pensez cela important. Le mieux que vous puissiez faire est de créer un script avec votre méthode de reproduction, cela nous aide beaucoup.
Au passage : vous êtes sûr d'utiliser la toute dernière version de Subversion, non ? :-) Il est possible que le bogue ait été corrigé, vous devriez tester votre méthode de reproduction avec l'arbre de développement de Subversion le plus récent.
En plus de la méthode de reproduction, nous aurons également besoin d'une description complète de l'environnement sous lequel vous avez reproduit le bogue. C'est-à-dire :
- Votre système d'exploitation
- La version et/ou la révision de Subversion
- Le compileur et les options de configuration que vous avez utilisés pour compiler Subversion
- Toutes modifications que vous avez apportées à Subversion
- La version de la Berkeley DB que vous utilisez avec Subversion, le cas échéant
- Tout autre chose qui pourrait être importante. Il vaut mieux recevoir trop d'informations que pas assez.
Une fois réunis tous ces éléments, vous serez prêt à rédiger le rapport. Commencez en donnant une description claire du bogue. C'est à dire que vous devez décrire le comportement attendu et le résultat obtenu. Même si le bogue peut vous sembler évident, il ne l'est pas forcément pour quelqu'un d'autre, il vaut donc mieux éviter de jouer aux devinettes. Continuez ensuite avec la description de votre environnement et la méthode de reproduction. Si vous voulez inclure des idées quant à la cause, ou même un correctif pour le bogue, c'est génial, voir http://svn.collab.net/repos/svn/trunk/www/hacking.html#patches pour les instructions pour l'envoi de correctifs.
Envoyez toutes ces informations à dev@subversion.tigris.org, ou, si vous avez déjà contacté la liste de développeurs et qu'on vous a demandé de rapporter le problème, rendez-vous sur le système de référencement de problèmes et suivez les instructions. Merci. Nous savons qu'un bon rapport demande beaucoup de travail, mais c'est un gain de temps important pour nos développeurs et un grand pas vers la correction du bogue.
| Annexe C | | Annexe E |
