How do I create a bug report/fr
│ Afrikaans (af) │
Deutsch (de) │
English (en) │
français (fr) │
português (pt) │
русский (ru) │
Ce document contient quelques lignes directrices pour l'utilisation du traqueur de bugs de FPC / Lazarus comme rapporteur. Ce document est écrit pour les utilisateurs de FPC / Lazarus qui identifient des bugs, ont des recommandations, veulent soumettre des correctifs ou trouvent d'autres problèmes et veulent les rapporter à l'équipe de développement de Lazarus.
Erreurs de compilation de code
Si vous aveze des erreurs de compilation de code issues de la dernière version Git, SVP veuillez contacter de manière appropriée la liste de diffusion de FPC ou la liste de diffusion de Lazarus ou utilisez un forum approprié. Comme cela, le problème pourra être résolu plus rapidement.
Vérifiez si le bug n'est pas déjà rapporté
Utilisez le champ de recherche dans la Vue des problèmes/questions (issues). Conseil : la recherche n'est pas très maline : si vous avez un problème avec TEdit.SelStart, recherchez "SelStart". Si le problème est déjà rapporté :
- Rouvrez-le si le rapport de bug a été résolu ou clos - Utilisez le bouton "Reopen Issue".
- Ajoutez une note, si vous avez reproduit le bug dans une situation différente de celle rapportée.
- Vous pouvez configurer le système pour qu'il surveille les modifications apportées à ce rapport de bogue. Utilisez le bouton "Monitor Issue".
Note : Vous devez vous connecter pour réaliser ces opérations, voir la section #Se connecter / Créer un nouveau compte.
Se connecter / Créer un nouveau compte
Vous devez vous connecter pour éditer ou soumettre un nouveau rapport. Si vous êtres connecté comme invité, vous devez vous déconnecter d'abord (les invités ne peuvent pas créer de rapports, ils peuvent seulement les consulter). Si vous avez déjà un compte, aller à la page de connection, sinon créez un nouveau compte dans la page d'inscription.
Que devrait être soumis dans le traqueur de bug ?
- Des bugs : si vous identifiez des erreurs, dysfonctionnement ou autres fautes dans FPC ou Lazarus.
- Des suggestions : Si vous avez identifié une meilleure façon de faire quelque chose.
- Des améliorations : Si vous faites fonctionner quelque chose en mieux.
SVP, veuillez noter : Le traqueur de bug n'est pas là pour déposer des questions. Cela devrait passer par les forums [1].
- pour le rapport, allez à la page traqueur de bugs de Lazarus. Vous devez être connecté, vois la section [#Se connecter / Créer un nouveau compte].
- Aller à la page de Rapport de problème. Remplissez-le avec tout ce que vous pouvez/sachez. Plus c'est précis, mieux c'est.
Bug
- Des champs importants sont les champs OS et Products et les étapes pour reproduire le problème. Si un problème ne peut pas être reproduit par les développeurs, ils ne peuvent pas commencer à le corriger ! N'omettez pas de mentionner votre architecture/configuration spécifique (32 ou 64 bit, petit ou gros boutiste si les deux sont possibles dans votre plate-forme, version de votre système d'exploitation).
- Si possible, SVP, envoyer une application test qui montre le bug. Cela accéléra probablement la correction.
- S'il y a une quelconque erreur graphique, il est utile d'envoyer une capture d'écran (partielle, en format jpg ou png pas en format bmp).
- Si c'est un plantage, essayez d'envoyer une trace arrière (backtrace). Voir Creating a Backtrace with GDB pour plus d'information.
- Vous pouvez essayer de reproduire le bug sur autant de plates-formes que vous le pouvez - cela aide à déterminer si c'est un problème de jeu de widgets (widgetset).
- Si vous avez une solution possible, vous pouvez ajouter le correctif - Voir Creating A Patch, cela accélérera le processus.
- Vous pouvez booster la résolution en soumettant une prime (bounty), voir Bounties.
Régression provoquée par une certaines révision
Si vous avez trouvé une révision dans le tronc qui a provoqué un bug, SVP, ajoutez aussi son numéro de révision SVN. Le rapport sera affecté en général à l'auteur de cette révision. Vous pouvez trouver une révision de qualité par un processus «bisect» qui est une recherche binaire sur les révisions. Il existe des outils pour aider à cela :
- Une commande Git git bisect. Pour cela, vous devez utiliser Git. Git est rapide dans ces opérations car tout l'historique des révisions est local et rien ne demande d'être ramené d'un serveur.
- Un script Perl svn-bisect, disponible dans CPAN. Il imite la commande "git bisect" mais travaille sur des données SVN directement.
Suggestion
Expliquer votre idée. Un prototype d'interface utilisateur.ou un exemple d'un autre outil utilisant la caractéristique peut être utile.
Amélioration
- Si vous avez implémenté une nouvelle fonctionnalité dans le code source ou amélioré la documentation dans les fichiers XML, créez un correctif - Voir Creating A Patch.
- Si vous avez amélioré une traduction dans un fichier de langue .po, joignez le fichier complet (par un diff).
- Si vous avez un autre fichier de ressource, p.ex. une icône, joignez-le au rapport.
Pièces jointes
Si vous avez des exemples à joindre de codes sources ou de projets pour le rapport de bug (fortement recommandé, voir Tips on writing bug reports), SVP, compressez-les en utilisant de préférence ces formats :
- zip (.zip)
- gzip (.gz)
- tar.gzip (.tgz/.tar.gz)
Les autres formats comme 7zip, Bzip et RAR sont aussi ok. De nos jours, des outils sont facilement disponibles.
Compréhension du status du rapport
Un problème peut avoir les états suivants :
- Nouveau (New) : il est entré dans le traqueur de bug, mais n'est pas affecté, reconnu (acknowledged), confirmé ou résolu.
- Reconnu (Acknowledged) : L'équipe Lazarus a vu le problème et défini sa cible, quoiqu'ils n'ont pas nécessairement vérifié que le bug était valide.
- Confirmé (Confirmed) : Un membre de l'équipe Lazarus a reproduit le bug ou accepté que la focntionnalité soit implémentée.
- Affectée (Assigned) : Le problème a été affecté un développeur Lazarus, qui essaiera de le corriger/l'implémenter.
- Résolu (Resolved) : La personne à qui le problème a été affecté pense que le problème peut être clos. Il fixe également la solution, par exemple fixe ou pas un problème.
- Retour d'information (Feedback) : le rapporteur devrait fournir un retour d'information pour répondre aux questions posées par l'équipe Lazarus, ou pour confirmer que le problème a été corrigé de manière satisfaisante.
- Clos (Closed) : Le rapporteur a testé le correctif at est d'accord avec celui-ci. Périodiquement, les problèmes résolus non fermés par leur rapporteur seront fermés par l'administrateur du traqueur de bugs.
Voir aussi
- Creating A Patch Si vous avex modifié un code source pour implémenter une solution, cet article vous aidera à l'ajouter à votre votre rapport de bug d'une manière efficace, ainsi, les développeurs pourront l'ajouter au code principal aussi vite que possible.
- Database bug reporting Information spécifique et programmes d'exemple pour les bugs de base de données.
- Moderating the bug tracker
- La page suivante contient de bons trucs sur le sujet How to Report Bugs Effectively.