| perlbug - comment soumettre des rapports de bug sur Perl |
perlbug - comment soumettre des rapports de bug sur Perl
perlbug [ -v ] [ -a address ] [ -s subject ] [ -b body | -f inputfile ] [ -F outputfile ] [ -r returnaddress ] [ -e editor ] [ -c adminaddress | -C ] [ -S ] [ -t ] [ -d ] [ -A ] [ -h ]
perlbug [ -v ] [ -r returnaddress ] [ -A ] [ -ok | -okay | -nok | -nokay ]
Un programme pour aider à produire des rapports de bug au sujet de perl ou des modules qui l'accompagne, et qui les poste.
Si vous avez trouvé un bug avec un port spécial (un de qui ne fait pas partie de la distribution standard), une distribution binaire, ou un module spécial (tel que Tk, CGI, etc) alors, s'il vous plaît, voyez la documentation qui est fournie avec cette distribution pour déterminer où rapporter des bugs.
perlbug est conçu pour être utilisé interactivement. Normalement aucun
argument n'est nécessaire. Lancez-le simplement, et suivez ses indications.
Si vous ne pouvez pas lancer perlbug (le plus souvent parce que votre configuration pour poster n'est pas reconnue par perlbug), vous devez composer votre propre rapport, et le poster à perlbug@perl.org. Vous pouvez alors trouver l'option -d utile pour obtenir une information sommaire dans ce cas.
En tout cas, pour rapporter un bug, assurez-vous, s'il vous plaît, d'avoir parcouru cette liste de contrôle:
perl -v à la ligne de commande pour la trouver.
Prenez connaissance des pièges usuels dans lesquels tombent les divers programmeurs de perl. Voyez la page de manuel perltrap.
Vérifiez dans la page de manuel perldiag la signification de tout message d'erreur obtenu. Si le message n'est pas dans perldiag, il n'est probablement pas produit par Perl. Consultez alors la documentation du système d'exploitation.
Si vous êtes sur une plate-forme non UNIX examinez la page de manuel perlport : certaines fonctions peuvent être non implémentées ou bien travailler différemment.
Essayez d'étudier le problème sous le débogueur Perl, si nécessaire. Voyez la page de manuel perldebug.
Un bon test de cas est presque toujours un bon candidat pour être dans la suite des tests de perl. Si vous avez le temps, arrangez votre test de telle manière qu'il s'insère aisément dans la suite des tests standards.
Souvenez-vous aussi d'inclure le message d'erreur exact, s'il y en a un. «Perl s'est plaint de quelque chose» n'est pas un message d'erreur exact.
Si vous obtenez un vidage mémoire [core dump] (ou équivalent), vous pouvez utiliser un débogueur (dbx, gdb, etc) pour produire une trace de la pile à inclure dans le rapport de bug. NOTE: à moins que votre Perl n'ait été compilé avec l'option debug-info (souvent G), il est possible que la trace de la pile soit difficile à utiliser parce qu'elle contiendra seulement les noms de fonction et non leurs arguments. Si possible, recompilez votre Perl avec l'option debug-info et reproduisez le vidage mémoire et la trace de la pile.
diff pour produire vos patchs
(diff est maintenu par les gens du GNU comme partie du paquetage
diffutils, donc vous devriez pouvoir l'obtenir dans l'un des dépôts des
logiciels du GNU). Si vous soumettez un patch, le compteur de mecs-cool à
perlbug@perl.org vous inscrira comme un sauveur du monde.
Votre patch peut vous être retourné avec des demandes de changements, ou des
demandes d'explications plus détaillées au sujet de votre correction.
Donnons ici quelques indices pour créer des patch de qualité :
Utilisez les options -c ou -u du programme diff (pour créer
un fichier diff avec contexte ou unifié).
Assurez-vous que le patch n'est pas inversé (typiquement le premier argument
de diff est le fichier original, le second argument est votre fichier
modifié). Testez votre patch en l'appliquant avec le programme patch
avant de l'envoyer. Essayez de suivre le même style que le code que
vous essayez de corriger. Assurez-vous vraiment que votre patch fonctionne
(faites un make test, si ce que vous essayez de corriger le permet).
perlbug pour soumettre le rapport ?perlbug est incapable de poster votre rapport après que vous l'ayez
tapé au clavier, vous devrez composer le message vous-même, ajouter la
sortie produite par perlbug -d et poster le tout à perlbug@perl.org.
Si, pour quelque raison, vous ne pouviez pas lancer du tout perlbug sur
votre système, assurez-vous d'inclure la sortie entière produite en lançant
perl -V (notez le V majuscule).
Que vous utilisiez perlbug ou que vous envoyiez l'email manuellement,
mettez une ligne Subject significative. «un bug» n'est pas significatif.
«perl plante» non plus, ni «À L'AIDE !!!». Ça n'apporte rien. Une description
compacte de ce qui ne va pas est bien préférable.
Ayant fait votre part, préparez-vous à attendre, à vous entendre
dire que le bug est dans votre code, ou même à n'obtenir aucune réponse du
tout. Les gens qui assurent la maintenance de Perl sont des gens occupés,
donc si votre problème est petit ou s'il est difficile à comprendre ou déjà connu,
ils peuvent ne pas vous répondre personnellement. S'il est important pour vous
que votre bug soit corrigé, surveillez le fichier Changes dans tout
développement publié depuis le moment où vous avez soumis un bug, et encouragez
les mainteneurs avec des mots gentils (mais jamais de flames!).
N'hésitez pas à renvoyer votre rapport de bug si la dernière version
de perl sort et que votre bug est toujours présent.
Kenneth Albanowski (<kjahds@kjahds.com>), subsequently doctored by Gurusamy Sarathy (<gsar@activestate.com>), Tom Christiansen (<tchrist@perl.com>), Nathan Torkington (<gnat@frii.com>), Charles F. Randall (<cfr@pobox.com>), Mike Guy (<mjtg@cam.a.uk>), Dominic Dunlop (<domo@computer.org>), Hugo van der Sanden (<hv@crypt0.demon.co.uk>), Jarkko Hietaniemi (<jhi@iki.fi>), Chris Nandor (<pudge@pobox.com>), Jon Orwant (<orwant@media.mit.edu>, and Richard Foley (<richard@rfi.net>).
perl(1), perldebug(1), perldiag(1), perlport(1), perltrap(1),
diff(1), patch(1), dbx(1), gdb(1)
Aucun de connu (devinez ce qui a dû être utilisé pour les rapporter ?)
Jean-Louis Morel <jl_morel@bribes.org>
| perlbug - comment soumettre des rapports de bug sur Perl |