Moderating the bug tracker/fr

│ Deutsch (de) │ English (en) │ français (fr) │ português (pt) │ русский (ru) │

Ce document contient quelques lignes directrices pour l'utilisation du traqueur de bug de Lazarus. Ce document est écrit pour deux groupes :

• les développeurs Lazarus, qui vont essayer de corriger les bugs
• les modérateurs qui vont supporter la gestion des problèmes en les priorisant et s'assurant qu'ils sont reproductibles.

Nous utiliserons le terme d'équipe Lazarus pour ces desux groupes.

Cycle de vie d'un problème

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.

Comment les modérateurs soutiennent les développeurs Lazarus ?

Reconnaître les problèmes

Définir la cible

L'étape la plus importante quand vous reconnaissez un problème est de définir le champ cible. Le champ cible aide les développeurs Lazarus à prioriser leur effort de correction de bug. Souvent, ils ont trois options : prochaine livraison mineure (p.ex. 1.6.2), prochaine livraison majeure (p.ex. 1.8) ou post prochaine livraison majeure (p.ex. post 1.8). Pour une explication de ces options, voir Road To 1.0#1.0 or after 1.0.

• prochaine livraison mineure : correctifs, régressions (i.e. des choses qui marche dans la livraion actuelle, mais qui sont cassées dans la version svn) et plantages qui peuvent occasionner des pertes de données.
• prochaine livraion majeure : améliorations, changement majeur de conception, nouvelles fonctionnalités.
• post prochaine livraison majeure : choses qui ne sont sans doute pas corrigées ou incluses dans la prochaine livraison majeure (p.ex. les jeux de widgets)

Il y a deux champs pour la cible :

• LazTarget, qui est utilisée pour sélectionner des problèmes pour plusieurs (sous-) projets à la fois, p.ex. Lazarus, Lazarus/paquets et Lazarus/correctifs.
• version cible, qui est utilisée par la feuille de route.

Eliminer les entrées en double

En regardant les 'nouveaux' problèmes, vous pouvez avoir besoin de retirer des doublons qui surgissent car des personnes sont soumis le même problème en même temps. Parfois, le traqueur de bug prend beaucoup de temps pour traiter le nouveau rapport et le rapporteur devient impatient et clique sur Submit à nouveau. De tels problèmes ne peuvent être supprimés.

Référer les questions à la liste de diffusion et aux forums

Si un problème ne décrit pas un bug mais est seulement une question (ou que le rapporteur ne sait pas comment utiliser une certaine fonctionnalité) Vous pouvez le renvoyer à la liste de diffusion et / ou aux forums pour poser sa question. Alors vous pouvez résoudre le problème avec la résolution "Ne nécessite aucun changement". Si vous le souhaitez, vous pouvez fournir une réponse courte à sa question, mais le traqueyr de bug est là pour entrrer des bugs et des demandes de fonctionnalité, pas pour fournir du support.

Ajout de relations à d'autres problèmes

Le traqueur de bugs permet d'établir des relations entre problèmes.

La relation la plus faible est Related (associé). Cela reliera seulement deux problèmes. Cela peut être utile jusqu'à ce que vous fixiez un problème, il peut corriger le(s) problème(s) associé(s) aussi.

Si deux rapports décrivent le même problème, vous pouvez mettre Duplicate of au rapport le plus récent. L'autre rapport reçoit alors un lien à ce problème avec Has duplicate.

Vous pouvez utiliser une relation Parent - enfant (Parent - Child) entre deux problèmes pour décrire une dépendance. En vue de corriger le problème parent, le problème enfant doit être résolu en premier. Parfois, il est utile de cloner un (gros) problème et de décrire ses parties en problèmes enfants séparés.

Moving to the patches subproject

Patches can be moved to the patches subproject. Patches are more visible there and can be managed separately from other issues.

Referring to the fpc bug tracker

If a bug is not in the IDE or the LCL, but in the RTL, FCL or the compiler, you can move the issue to the FPC project in the bug tracker.

Referring to the Lazarus-CCR bug tracker

Some projects or components hosted on Lazarus-CCR use the Lazarus bug tracker for tracking issues. Those issues should not reside in the Lazarus project: you should move them to the Lazarus CCR bug tracker.

Confirming issues

Most of the time, the first step in fixing an issue is creating a small example program that demonstrates the issue. Reporters vary in the effort they make when submitting their initial report. Some people add test programs to their report (very nice), some people only add a code snippet (better than nothing) and some people add nothing at all. Not all reports provide adequate steps for others to reproduce the supposed issue. Going to the length of adding a small, compilable example program speeds identification and resolution of the issue you have identified.

If it is not clear from the Mantis bug report, you can ask the reporter to give steps to reproduce this issue and/or a test project.

If you manage to reproduce the issue, then you can set the issue to Confirmed.

Assigning issues to yourself

If you think you can fix a reported issue, you can assign the issue to yourself.
Other users, including the original reporter will then know the issue is under someones attention.
Once you have provided a patch [1] you then set the target to the next stable release and unassign the issue (assign to nobody). This will signal to the maintainers that a patch is being offered for review.
If it turns out that you are unable to fix the issue you have assigned to yourself, simply unassign it.

GTK 1 issues

The gtk (i.e. the gtk version 1) widget set is not actively supported anymore by the Lazarus team, see announcement. If there is no problem when the gtk2 widget set is used instead, then the issue can be resolved with state suspended.

Tags

Below is a table with the tags utilized to mark groups of bug reports which aren't easily defined by the other options and their description.

Tag	Description
gtk2	Represents all gtk2 specific bugs and is used to track what needs to be fixed before gtk2 becomes the default Linux widgetset.

Voir aussi

• How do I create a bug report information générale sur la soumission de bug, ce qui devrait être couvert dans un rapport de bug, et l'utilisation du traqueur de bug.