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.

Déplacement vers un sous-projet de correctifs

Les correctifs peuvent être déplacés vers un sous-projet de correctifs. Les correctifs sont plus visibles là et peuvent être gérés séparément d'autres problèmes.

Se référant au traqueur de bug de FPC

Si le bug n'est pas dans l'IDE ou dans la LCL, mais dans la RTL, FCL ou le compilateur, vous pouvez déplacer le problème dans le projet FPC dans le traqueur de bug.

Se référant au traqueur de bug de Lazarus-CCR

Certains projets ou composants hébergés dans le Lazarus-CCR utilise le traqueur de bug pour les problèmes. Ces problèmes ne devraient pas être dans le projet Lazarus : vous devriez le déplacer dans le traqueur de bug de Lazarus-CCR.

Confirmation de problèmes

La plupart du temps, la première étape dans la correction d'un problème est de créer un court exemple qui démontre le problème. Les rapporteurs font des efforts divers quand ils soumettent leur rapport initial. Certaines personnes ajoute un programme de test à leur rapport (très sympa), d'autres ajoutent un extrait de code (mieux que rien) et d'autres encore rien du tout. Tous les rapports ne fournissent pas les étapes adéquates pour les autres pour reproduire le problème supposé.

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. En ajoutant un petit programme compilable accélère l'identification et la résolution du problème que vous avez identifié.

Si cela n'est pas clair dans le rapport de bug Mantis, vous pouvez demander au rapporteur de donner les étapes pour reproduire ce problème et/ou un projet de test.

Si vous parvenez à reproduire le problème, vous pouvez mettre le problème à Confirmed.

Affecter des problèmes à soi-même

Si vous pensez pouvoir corriger un problème rapporté, vous pouvez vous affecter le problèmes.
Les autres utilisateurs, dont le rapporteur original, sauront que le problème est pris en considération.
Une fois que vous avez fourni un correctif Creating_A_Patch vous pouvez alors définir la cible à la prochaine version stables et désaffecter le problème (affecter à personne). Cela signalera aux mainteneurs qu'un correctif est prêt pour une revue.

S'il s'avère que vous ne parvenez pas à résoudre le problème que vous vous êtes attribué, il suffit de l'annuler.

Problèmes de GTK 1

Le jeu de widgets gtk (i.e. le gtk version 1) n'est plus activement supporté par l'équipe Lazarus, voir announcement. S'il n'y a pas de problème quand le jeu de widget gtk2 est utilisé à la place, alors le problème est résolu avc l'état Suspended.

Etiquettes

En dessous se trouve une table avec les étiquettes utilisée pour marquer les groupes de rapports de bug qui ne sont pas simplement définis par d'autres options et leur description.

Tag	Description
gtk2	Représente tous les bugs spécifiques à gtk2 et est utilisé pour tracer ce qui doit être corrigé avant que gtk2 ne devienne le jeu de widget par défaut de Linux.

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.