Utilisation de l'outil de suivi des bugs GRASS

lun 01-11-2010 Eve Rousseau

SIG OpenSource

Consulter et renseigner le bug-tracker GRASS : la nouvelle version du bug-tracker sous GForge.

Le contenu des projets Open-Source est en constante mutation, en raison du dialogue permanent qui s'établit entre développeurs et utilisateurs (en fait surtout les "power-users" qui sont les principaux testeurs du code). Ce dialogue se fait au travers d'un outil qu'on appelle "bug-tracker", autrement dit un "outil de suivi des bugs".

Le bug-tracker GRASS

Il existe un ancien outil de suivi des bogues GRASS : il contient les anciens rapports de bogues et on peut toujours facilement lancer une recherche sur les problèmes et les correctifs apportés.
Depuis le 12 février 2007, Maciej Sieczka a mis en ligne sur GForge le nouvel outil de suivi des bogues GRASS qui contiendra désormais tous les nouveaux rapports de bogues. Voici une brève description de ce nouveau bug-tracker...

Catégories thématiques du traqueur de bogues

Il existe trois catégories thématiques concernant GRASS :

le code source lui-même bien entendu,
la documentation officielle autrement dit les manuels des différentes versions,
le contenu du site internet grass.itc.it et de ses miroirs.

(Toutes demandes d'évolution qui concernent du code non-standard (modules développés par ailleurs et non-intégrés au code de GRASS), de la documentation ou des sites d'informations extérieurs au site officiel devraient être adressées directement à leurs auteurs/éditeurs).

Types de fiches du bug-tracker

Les fiches renseignées dans le bug-tracker peuvent être de trois natures distinctes :

"feature requests" autrement dit les souhaits de demande d'évolutions, par exemple si un utilisateur souhaite qu'une nouvelle fonctionnalité soit développée,
"issues", il s'agit là des bogues repérés dans le code existant,
"patches", pour les correctifs apportés à des anomalies existantes.

Chaque nouvelle fiche est prise en charge en son temps par un développeur, un rédacteur de documentation ou un rédacteur du site web.

Du bon usage du bug-tracker GRASS

Pour être utile, un nouveau rapport de bogue doit détailler les circonstances précises dans lesquelles le bogue s'est produit, par exemple avec un échantillon de données à l'appui, le type de dysfonctionnement constaté (notamment avec le message d'erreur exact renvoyé par le SIG).
De la même façon, une demande d'évolution fonctionnelle doit détailler le besoin de façon précise en passant en revue les données utilisées en entrée, et le résultat attendu. Parfois, il peut aussi être important d'expliciter le type d'algorithme qu'on voudrait voir implémenté ...

Avant de soumettre un rapport de bogue, il est indispensable de s'assurer qu'un rapport de bogue ou de demande d'évolution similaire n'ont pas déjà été soumis en faisant une recherche, ou encore que le bogue en question n'est pas provoqué par une mauvaise utilisation de la commande GRASS.
Bien entendu, tout utilisateur qui soumet un rapport s'engage à être disponible pour dialoguer avec le développeur à qui le traitement du bogue ou de l'évolution est attribué.
Ce travail est important pour le développement des logiciels Open-Source, il est au coeur des performances de ces outils et de leur amélioration constante : n'hésitez donc pas à consulter les rapports, à en renseigner de nouveaux et, le cas échéant, à proposer vos propres correctifs aux bogues rencontrés.