POSSFR AnnexeB

De Framalang Wiki.

Annexe A
Page d'accueil du projet
 Annexe C


Annexe B : Systèmes libres de suivi de bogues

Quel que soit le système de suivi de bogues qu'un projet choisit, il y a aura toujours quelqu'un pour s'en plaindre. Ce phénomène n'est pas nouveau, et aucun outil de développement partagé n'y échappe, mais il se fait encore plus sentir dans ce cas particulier. Je pense que c'est dû au fait qu'un tel outil est très visuel et interactif. Il est donc facile d'imaginer les améliorations qu'on pourrait y apporter (si seulement on en avait le temps) et de les décrire à tout le monde. Il vous faudra donc accepter les inévitables griefs avec un peu de philosophie. La plupart des systèmes proposés ci-dessous sont plutôt bons.

Tout au long de cette liste, le mot « problème » sera utilisé pour décrire les objets répertoriés dans le système de suivi. Mais souvenez vous que chaque système peut employer sa propre terminologie, ainsi vous pourrez également retrouver « artéfact » ou « bogue » ou d'autres termes encore.


Bugzilla est très populaire, maintenu activement et semble apprécié des utilisateurs. La version modifiée que j'emploie depuis quatre ans me satisfait tout à fait. Il n'est pas très personnalisable, mais c'est peut-être étrangement l'un de ses avantages : les installations de Bugzilla sont à peu près similaires partout : les développeurs sont déjà habitués à son interface et restent donc en terrain connu.

GNU GNATS est l'un des systèmes de suivi de bogues les plus anciens et est largement répandu. Ses points forts sont la diversité des interactions avec le programme (il peut être utilisé non seulement grâce à un navigateur Web, mais aussi par e-mail ou en ligne de commande), ainsi que le stockage des problèmes en texte brut. Le fait que tous les problèmes soient stockés sous forme de fichiers textes sur disque rend plus aisée l'écriture d'outils d'analyse des données (par exemple, afin de générer des rapports statistiques). GNATS sait aussi traiter les e-mails par différents moyens et les mettre en relation avec les problèmes correspondants en se basant sur l'en-tête. L'enregistrement des conversations utilisateurs/développeurs est, de ce fait, très simple.

RT est présenté comme « un système professionnel permettant à un groupe de personnes de gérer intelligemment et efficacement les tâches, les problèmes et les demandes émanant de la communauté des utilisateurs », ce qui est un plutôt bon résumé. RT dispose d'une interface Web assez léchée, et semble bénéficier d'une large base d'utilisateurs. L'interface est un peu complexe visuellement, mais on s'y habitue et elle gêne moins avec le temps. RT est sous licence GNU GPL (ce n'est étrangement pas clairement affiché sur le site Web).

Trac est un peu plus qu'un système de suivi de bogues : c'est plutôt un wiki couplé à un système de référencement de bogues. Il utilise les liens wiki pour connecter les problèmes, les fichiers, les modifications sous contrôle de versions et les pages wiki classiques. Il est simple à mettre en œuvre et s'intègre à Subversion (voir l'Annexe A. Solutions libres de gestion de versions).

Roundup est assez facile à installer (le seul pré-requis est Python 2.1 ou supérieur) et simple d'utilisation. Il propose des interfaces Web, e-mail et par ligne de commande. Les formulaires de données des problèmes et l'interface Web sont personnalisables, tout comme une partie de sa logique de changement d'état.

Mantis est une application Web de système de suivi de bogues écrite en PHP, utilisant MySQL pour le stockage des données. Elle possède les fonctionnalités que vous attendez d'un système de référencement de bogues. Personnellement, je trouve l'interface propre, intuitive et agréable à l'œil.

Flyspray est une application Web de suivi de bogues écrite en PHP. Sur sa page Web, elle est décrite comme « décompliquée » et parmi ses fonctionnalités, on retrouve : le support de bases de données multiples (MySQL et PGSQL actuellement), la gestion de projets multiples, la surveillance de tâches avec des alertes de modifications (par e-mail ou Jabber), un historique complet des tâches, des thèmes par feuilles de style CSS, l'ajout de pièces jointes, des outils de recherche avancés (mais toujours simple à utiliser), le support des flux RSS/Atom, la saisie au format wiki ou texte brut, le vote et la représentation graphique des dépendances.

L'idée de base de Scarab est d'offrir un système de suivi de bogues très complet et personnalisable. Il propose plus ou moins de rassembler les fonctionnalités assurées par les autres systèmes de référencement de bogues : l'entrée de données, les requêtes, les rapports, les notifications aux personnes concernées, la gestion collaborative des commentaires et le suivi des dépendances. La personnalisation se fait au travers de pages Web d'administration. Vous pouvez multiplier les « modules » (projets) actifs au sein d'une même installation de Scarab. Dans un module donné, vous pouvez créer de nouveaux types de problèmes (défauts, améliorations, tâches, requêtes de support, etc.) et ajouter des attributs arbitraires pour adapter le système de référencement aux besoins spécifiques de votre projet. Vers fin 2004, Scarab se rapprochait de la sortie de sa version 1.0.

Le Debian Bug Tracking System est surprenant par le fait que toutes les saisies ou manipulations de problèmes se font par e-mail : chaque problème se voit attribuer sa propre adresse email. Le DBTS s'adapte très bien à la taille de n'importe quel projet, http://bugs.debian.org/ recense par exemple 277 741 problèmes.

Comme toutes les interactions se font par le client de messagerie classique, un environnement familier et facilement accessible pour la plupart des personnes, le DBTS est très adapté à l'enregistrement de nombreux rapports qui nécessitent tri et prompte réaction. Il n'est évidemment pas non plus exempt de défauts. Les développeurs doivent passer par une étape d'apprentissage du système de commandes par e-mail, et les utilisateurs doivent écrire leurs rapports de bogue sans pouvoir s'inspirer d'un formulaire en ligne pour connaître les informations à transmettre. Il existe des outils pour aider les utilisateurs à envoyer de meilleurs rapports de bogues tels que le programme de rapport de bogue en ligne de commande ou le paquet debbugs-el pour Emacs. Mais la plupart des gens n'utiliseront pas ces outils, ils se contenteront d'écrire les e-mails à la main et suivront (ou pas) les consignes pour écrire un bon rapport de bogue données par votre projet. Le DBTS propose une interface Web en lecture seule pour la consultation et la recherche de problèmes.

Suivi des dossiers d'incident

Ces programmes sont plus axés sur le suivi de l'assistance que sur le suivi des bogues. Un système de référencement de bogues sera sans aucun doute plus adapté, mais je vais aussi lister ces programmes afin d'être exhaustif, et parce qu'il n'est pas inconcevable qu'un projet exotique tire meilleur parti d'un système de suivi des dossiers d'incidents que d'un système de référencement de bogues classique.

BTT se situe à mi-chemin entre le suivi des dossiers d'incidents et le système de référencement de bogues. Il propose des options de confidentialité qui sont plutôt rares parmi les systèmes de référencement de bogues libres : les utilisateurs sont rangés dans les catégories Personnel, Ami, Client ou Anonyme, et la quantité d'information disponible dépend de la catégorie à laquelle vous appartenez. On retrouve l'intégration des e-mails, une interface en ligne de commande et des mécanismes de conversion des e-mails en dossiers. Il propose également des outils pour suivre des informations qui ne sont pas liées à des dossiers particuliers comme la documentation interne ou les FAQs.



Annexe A
Page d'accueil du projet
 Annexe C
Récupérée de « http://www.framalang.org/wiki/POSSFR_AnnexeB »