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

From Lazarus wiki
Jump to navigationJump to search
 
(10 intermediate revisions by the same user not shown)
Line 33: Line 33:
  
 
=== Référer les questions à la liste de diffusion et aux forums ===
 
=== 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.
  
* * A FINIR  * *
+
=== Ajout de relations à d'autres problèmes ===
 +
Le traqueur de bugs permet d'établir des relations entre problèmes.
  
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.
+
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.
  
=== Ajout de relations à d'autres problèmes ===
+
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 bug tracker supports setting relations between issues.  
 
  
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.
 
|}
 
|}
  
 
=Voir aussi=
 
=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.
 
* [[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 13: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.