Gestion des bogues d'Inkscape

Les bogues d'Inkscape sont rapportés et gérés sur GitLab (traqueur pour les utilisateurs ; traqueur pour les développeurs) et sur l'ancien traqueur sur Launchpad. Tout utilisateur peut créer et commenter des rapports, et s'affecter au traitement d'un bogue donné. Les membres de l'équipe des bogues d'Inkscape peuvent spécifier des priorités et des étiquettes.

Liens importants

• Bogues d'Inkscape sur Launchpad (ceux-ci doivent être transférés sur GitLab)
• Bogues d'Inkscape sur GitLab
• Équipe des bogues d'Inkscape — contactez les développeurs sur la liste de diffusion ou par messagerie instantanée pour devenir un membre de l'équipe.

Statut des bogues

Launchpad permet d'assigner différents statuts aux bogues. Leur utilisation dans Inkscape est expliquée ici.

• New (nouveau) : ce bogue vient d'être rapporté, et l'on ne sait pas s'il est reproductible. Essayez de le reproduire sur votre ordinateur.
• Confirmed (confirmé) : ce bogue a été reproduit et il est confirmé qu'il provient d'Inkscape. Vous pouvez travailler à son inspection et sa correction.
• Triaged (classé) : un membre de l'équipe des bogues a vérifié le bogue et lui a assigné une importance. Les développeurs d'Inkscape acceptent de travailler pour résoudre le bogue.
• In Progress (en cours) : quelqu'un travaille actuellement à la correction du bogue. N'utilisez pas ce statut pour indiquer que vous souhaitez travailler sur un bogue donné, ou que vous travaillerez dessus au bout d'un moment ; placez ce paramètre une fois que vous avez effectivement commencé à travailler à la correction.
• Fix Committed (correction soumise) : le bogue est corrigé dans la version de développement (la branche lp:inkscape). Si vous avez soumis une correction, mais n'êtes pas sûr qu'elle fonctionne, par exemple si le problème se produit uniquement sur une plateforme à laquelle vous n'avez pas accès, laissez le statut précédent.
• Fix Released (correction publiée) : le bogue est corrigé dans la dernière livraison stable d'Inkscape. Utilisez également ce statut pour les bogues qui ne sont apparus que dans la version de développement, et n'ont jamais été rencontrés dans une version stable.
• Incomplete (incomplet) : l'utilisateur qui a rapporté le bogue n'a pas fourni suffisamment d'informations pour que le problème puisse être vraiment identifié ou reproduit. Si personne d'autre ne rencontre un problème similaire, il sera marqué comme invalide au bout d'un moment.
• Invalid (invalide) : ce problème ne provient pas d'Inkscape, ou l'utilisateur n'a pas répondu aux requêtes exigeant plus d'informations.
• Won't Fix (ne sera pas traité) : le problème ne sera jamais corrigé dans Inkscape en raison de choix de conception ou parce qu'il s'étend au-delà de la portée du programme. Par exemple, une requête pour éditer des clips audio ou réécrire Inkscape dans un autre langage de programmation.

Importance du bogue

L'importance indique à quel point le bogue est sérieux.

• Critical (critique) : comportement très sérieusement incorrect qui va sévèrement déranger une grande quantité d'utilisateurs. Exemples : plantages reproductibles après une action courante ; perte de données dans un document ; corruption de données dans un document ; régressions sévères dans les fonctionnalités ; compilation rendue impossible sur plus d'un plateforme (Linux, Mac, Windows, autre).
• High (élevée) : comportement sérieusement incorrect qui va probablement déranger de nombreux utilisateurs. Exemples : plantage reproductible après une séquence d'opérations peu commune ; perte de données utilisateur (par ex. corruption du fichier de préférences) ; sortie non conforme au format SVG ; mauvaise interprétation de documents conformes au format SVG ; sortie de fichier incorrecte ; fuite de mémoire majeure ; compilation rendue impossible sur seulement une plateforme.
• Medium (moyenne) : comportement modérément sérieusement incorrect qui va probablement déranger un certain nombre d'utilisateurs. Exemples : plantage dans des circonstances obscures et peu probables ; interface utilisateur n'adhérant pas aux lignes directrices ; qualité de rendu inférieure au standard ; mauvaise performance ; fuite de mémoire mineure ; problèmes de compilation sur des plateformes exotiques mais à jour.
• Low (faible) : bizarrerie ou déviation du comportement attendu qui peut déranger un petit nombre d'utilisateurs. Exemples : problème mineur dans le rendu ; positionnement des commandes dérangeant ; comportement dérangeant ou limitation des fonctionnalités d'une commande existante ; faible performance durant des opérations obscures ; traduction incorrecte ; problèmes de compilation sur des plateformes obsolètes.
• Wishlist (souhait) : absence de fonctionnalité qui peut déranger certains utilisateurs. Exemples : pas de fonction d'autosauvegarde ; export vers un format de fichier exotique non supporté ; pas de glisser-déposer entre Inkscape et Word.

Mots-clés

Les mots-clés placent les bogues dans des catégories reliées par sous-système, plateforme, ou zone générale de fonctionnalité dans Inkscape. Ils sont particulièrement utiles aux développeurs qui travaillent sur une zone spécifique du code et souhaitent corriger certains bogues d'un coup. Voici une liste incomplète des mots-clés les plus importants.

• blocker : un bogue qui doit être corrigé avant la prochaine livraison.
• crash : plantage.
• regression : quelque chose qui fonctionnait dans une version précédente et ne fonctionne plus.
• linux : le problème ne survient que sous Linux.
• win32 : le problème ne survient que sous Windows.
• osx : le problème ne survient que sur Mac OS X.

Suggestions

Voici la méthodologie générale pour le travail avec les bogues.

Soyez poli(e). Il faut quelques efforts à l'utilisateur pour venir sur notre site, naviguer à la section de rapport de bogues, et rédiger un rapport. S'ils savent que leur rapport sera traité sérieusement et professionnellement, ils respecteront le système et s'investiront davantage pour nous aider à résoudre le problème.

Ne fermez pas un bogue non reproductible à moins qu'une dose raisonnable d'effort soit mise dans sa reproduction, et laissez-le se périmer quelque temps avant de le fermer — quelqu'un peut venir s'insérer dans les commentaires avec un meilleur rapport (dans certains cas, nous n'arrivions pas à reproduire le bogue, mais grâce à l'assistance impliquée de l'utilisateur, nous avons pu nous rapprocher et corriger le problème, et l'utilisateur a pu valider).

Clarifiez. S'il vous a fallu un certain temps pour comprendre de quoi il s'agit, changez le résumé ou ajoutez un commentaire, pour rendre l'affaire évidente à ceux qui liront le traqueur après vous (particulièrement s'il s'agit de la personne qui peut effectuer la correction). Par exemple « étrange bogue de défilement » devrait être remplacé par « problème de rendu lors du défilement quand un clone masqué est déplacé », et « Inkscape plante avec ce fichier » par « plantage lors du déplacement des points du dégradé d'un clone parent ».

Lorsque vous fermez un bogue avec le statut « correction soumise » (fix committed), ajoutez un commentaire qui inclut le numéro de révision de la première version sans le bogue. Pour les bogues qui ne sont apparus que dans une version de développement et ont été corrigés avant la livraison stable, donnez-leur directement le statut « correction publiée » (fix released) dès qu'ils sont corrigés dans la branche de développement.

Recherchez toujours les requêtes similaires ou dupliquées avant de fournir de nouveaux rapports. Lorsque vous choisissez quel rapport doit être marqué comme un double et lequel doit être laissé valide, les rapports les plus anciens devraient avoir la priorité sur les rapports plus récents. Il peut y avoir des exceptions si le rapport plus récent contient significativement plus d'informations. Si approprié, copiez les informations utiles depuis le rapport fermé vers le rapport laissé ouvert.