Difference between revisions of "Moderating the bug tracker/fr"

From Lazarus wiki
Jump to navigationJump to search
m
 
(15 intermediate revisions by the same user not shown)
Line 7: Line 7:
  
 
= Cycle de vie d'un problème =
 
= Cycle de vie d'un problème =
−
An issue can have the following states:
+
Un problème peut avoir les états suivants :
−
* new: it has entered in the bug tracker
+
* Nouveau (''New'') : il est entré dans le traqueur de bug, mais n'est pas affecté, reconnu (''acknowledged''), confirmé ou résolu.
−
* acknowledged: the Lazarus team has seen the issue and has set its target
+
* 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.
−
* confirmed: a member of the Lazarus team has duplicated the bug or agrees that the feature should be implemented
+
* Confirmé (''Confirmed'') : Un membre de l'équipe Lazarus a reproduit le bug ou accepté que la focntionnalité soit implémentée.
−
* assigned: the issue has been assigned to a Lazarus developer, who will try to fix it
+
* Affectée (''Assigned'') : Le problème a été affecté un développeur Lazarus, qui essaiera de le corriger/l'implémenter.
−
* resolved: the person to whom the issue was assigned thinks the issue can be closed. Then he also sets the resolution, for example '''fixed''' or '''not an issue'''.
+
* 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'''.
−
* closed: the reporter tested the fix and agrees with the fix. Periodically resolved issues that have not been closed by the reporter, will be a closed by the bug tracker administrator.
+
* 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 ? =
 
= Comment les modérateurs soutiennent les développeurs Lazarus ? =
Line 19: Line 20:
 
== Reconnaître les problèmes ==
 
== Reconnaître les problèmes ==
 
=== Définir la cible ===
 
=== Définir la cible ===
−
The most important step when you acknowledge an issue, is that you set the target field. The target field helps the Lazarus developers to prioritize their bug fixing effort. Generally there are three options: '''next minor release''' (e.g. 1.6.2), '''post next major release''' (e.g. 1.8) or '''post next major release''' (e.g. post 1.8). For an explanation of these options, see [[Road To 1.0#1.0 or after 1.0]].
+
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)
  
−
* next minor release: patches, regressions (i.e. things that work in the current release, but got broken in the svn version) and crashes that can cause data loss.
+
Il y a deux champs pour la cible :
−
* next major release: improvements, major design changes, new features.
+
* 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.
−
* post next major release: things that are not likely to be fixed or incuded in the next major release (e.g. new widgetset).
+
* version cible, qui est utilisée par la [http://bugs.freepascal.org/roadmap_page.php feuille de route].
−
 
 
−
There are two fields for the target:  
 
−
* LazTarget, which can be used to select issues for several (sub-)projects at once, for example Lazarus, Lazarus/packages and Lazarus/patches.  
 
−
* Target version, which is used by the [http://bugs.freepascal.org/roadmap_page.php road map].
 
  
 
=== Eliminer les entrées en double ===
 
=== Eliminer les entrées en double ===
−
When looking at a 'new' issue, you may need to remove duplicates that have arisen because people submitted the same issue more than once. Sometimes the bugtracker takes a long time to process the new report and the reporter gets impatient and clicks on submit again. Such 'issues' can be deleted.
+
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 ===
 
=== Référer les questions à la liste de diffusion et aux forums ===
−
If an issue doesn't describe a bug, but is only question (or the reporter doesn't know how to use certain feature) you can refer him to the mailing list and/or the forums to ask his question. Then you can resolve the issue with resolution "'''no change required'''". If you wish, you can provide a short answer to his question, but the bug tracker is for entering bugs and feature requests, not for providing support.
+
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 ===
 
=== Ajout de relations à d'autres problèmes ===
−
The bug tracker supports setting relations between issues.  
+
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'''.
  
−
The weakest relation is '''Related'''. This merely links the two issues. This can be useful since if you fixed one issue, it may fix the related issue(s) too.
+
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.
  
−
If two reports decribe the same issue, then you can set '''Duplicate of''' to the newest report. The other report then receives a link to that issue with '''Has duplicate'''.
+
=== 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.
  
−
You can use the '''Parent - Child''' relation between two issues to describe dependency. In order to fix the '''Parent''' issue, the '''Child''' issue must be fixed first. Sometimes it is usefull to ''clone'' a (big) issue and describe part of it in a separate '''Child''' issue.
+
=== 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.
  
−
=== Moving to the patches subproject ===
+
=== Se référant au traqueur de bug de Lazarus-CCR ===
−
Patches can be moved to the patches subproject. Patches are more visible there and can be managed separately from other issues.
+
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.
  
−
=== Referring to the fpc bug tracker ===
+
== Confirmation de problèmes ==
−
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.
+
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é.
  
−
=== Referring to the Lazarus-CCR bug tracker ===
+
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é.
−
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 ==
+
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.
−
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.
+
Si vous parvenez à reproduire le problème, vous pouvez mettre le problème à '''Confirmed'''.
  
−
If you manage to reproduce the issue, then you can set the issue to '''Confirmed'''.
+
== Affecter des problèmes à soi-même ==
 +
Si vous pensez pouvoir corriger un problème rapporté, vous pouvez vous affecter le problèmes.<br/>
 +
Les autres utilisateurs, dont le rapporteur original, sauront que le problème est pris en considération.<br/>
 +
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.<br/>
  
−
== Assigning issues to yourself ==
+
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.
−
If you think you can fix a reported issue, you can assign the issue to yourself.<br>
 
−
Other users, including the original reporter will then know the issue is under someones attention.<br>
 
−
Once you have provided a patch [http://wiki.lazarus.freepascal.org/Creating_A_Patch] 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.<br>
 
−
If it turns out that you are unable to fix the issue you have assigned to yourself, simply unassign it.
 
  
−
== GTK 1 issues ==
+
== Problèmes de GTK 1 ==
−
The gtk (i.e. the gtk version 1) widget set is not actively supported anymore by the Lazarus team, see [http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-November/047069.html announcement]. If there is no problem when the gtk2 widget set is used instead, then the issue can be resolved with state suspended.
+
Le jeu de widgets gtk (i.e. le gtk version 1) n'est plus activement supporté par l'équipe Lazarus, voir [http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-November/047069.html 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.
  
−
=Tags=
+
=Etiquettes=
  
−
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.
+
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.
  
 
{| class="wikitable"
 
{| class="wikitable"
 
! Tag !! 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.
+
|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.
 
|}
 
|}
  
−
=See also=
+
=Voir aussi=
−
* [[How do I create a bug report]] general information on submitting bugs, what should be covered in a bug report, and using the bug tracker.
+
* [[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.
 +
<br/>

Latest revision as of 14:26, 6 March 2017

│ 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.


Retrieved from "http://wiki.freepascal.org/index.php?title=Moderating_the_bug_tracker/fr&oldid=107676"