Comment je m'y prend ? Hum ... Y'a deux cas : signaler un bug, corriger un bug.
Signaler un bug consiste à donner le maximum d'informations pertinentes sur un bug et à envoyer le tout aux développeurs. Pour un plantage, il faut par exemple lancer l'application avec gdb, après copier/coller le résultat de la commande backtrace après plantage. Pour un bug qui ne plante pas, il faut expliquer pas à pas la démarche pour arriver au bug, et le comportement qu'on aurait désiré. Pour envoyer le bug, il faut voir le site web du programme. Gnome a son application dédiée. Chaque cas est différent donc.
Souvent, le bug est connu, est en cours de correction, ou alors déjà corrigé dans le CVS. C'est pour ça qu'il faut toujours commencer par signaler le bug.
Si c'est un nouveau bug, et qu'aucun développeur du projet ne s'y attarde, autant le corriger soit-même (on est jamais aussi bien servi que par soi-même :-D). Il faut commencer par télécharger la toute dernière version (surtout pas la dernière version stable qui comporte d'ancien bug déjà corrigé, ou une API désuette) : tarball, cvs, subversion, etc. (cf. le site web du projet) Ensuite, il faut compiler le projet, et vérifier que le bug existe toujours. Ben oui, rien ne sert de défoncer une porte ouverte avec un bazooka hein.
Si le bug existe toujours, il faut le traquer. Il vaut mieux connaître les commandes break et where de gdb, et avoir un peu d'expérience avec cet outil. Perso, je commence par laisser planter le programme et voir où je suis avec where (équivalent à backtrace au passage). Ensuite, je remonte à la source en posant un point d'arrêt sur la fonction ayant plantée et je relance le programme. Cette recherche est souvent longue et épuisante.
Une fois le bug cerné, 90% du boulot est fait :-D Il ne reste plus qu'à comprendre pourquoi ça plante, et corriger le bug. On recompile le programme. Si ça marche pas .... on recommence. Si ça passe, il FAUT envoyer son patch aux développeurs, sinon tout ce travail n'aura servi à rien. Au faut alors faire un diff -u ancien_fichier nouveau_fichier >~/mon.patch et l'envoyer par email. C'est pour ça qu'il vaut mieux faire un cp fichier fichier.old avant d'éditer n'importe quel fichier !
[^] # Re: Mes contributions
Posté par Victor STINNER (site web personnel) . En réponse au journal De la difficulté de contribuer à des gros projets. Évalué à 6.
Signaler un bug consiste à donner le maximum d'informations pertinentes sur un bug et à envoyer le tout aux développeurs. Pour un plantage, il faut par exemple lancer l'application avec gdb, après copier/coller le résultat de la commande backtrace après plantage. Pour un bug qui ne plante pas, il faut expliquer pas à pas la démarche pour arriver au bug, et le comportement qu'on aurait désiré. Pour envoyer le bug, il faut voir le site web du programme. Gnome a son application dédiée. Chaque cas est différent donc.
Souvent, le bug est connu, est en cours de correction, ou alors déjà corrigé dans le CVS. C'est pour ça qu'il faut toujours commencer par signaler le bug.
Si c'est un nouveau bug, et qu'aucun développeur du projet ne s'y attarde, autant le corriger soit-même (on est jamais aussi bien servi que par soi-même :-D). Il faut commencer par télécharger la toute dernière version (surtout pas la dernière version stable qui comporte d'ancien bug déjà corrigé, ou une API désuette) : tarball, cvs, subversion, etc. (cf. le site web du projet) Ensuite, il faut compiler le projet, et vérifier que le bug existe toujours. Ben oui, rien ne sert de défoncer une porte ouverte avec un bazooka hein.
Si le bug existe toujours, il faut le traquer. Il vaut mieux connaître les commandes break et where de gdb, et avoir un peu d'expérience avec cet outil. Perso, je commence par laisser planter le programme et voir où je suis avec where (équivalent à backtrace au passage). Ensuite, je remonte à la source en posant un point d'arrêt sur la fonction ayant plantée et je relance le programme. Cette recherche est souvent longue et épuisante.
Une fois le bug cerné, 90% du boulot est fait :-D Il ne reste plus qu'à comprendre pourquoi ça plante, et corriger le bug. On recompile le programme. Si ça marche pas .... on recommence. Si ça passe, il FAUT envoyer son patch aux développeurs, sinon tout ce travail n'aura servi à rien. Au faut alors faire un diff -u ancien_fichier nouveau_fichier >~/mon.patch et l'envoyer par email. C'est pour ça qu'il vaut mieux faire un cp fichier fichier.old avant d'éditer n'importe quel fichier !
@+ Haypo