Éclosion de Mantis 1.1.0

Posté par  (site web personnel) . Modéré par Jaimé Ragnagna.
Étiquettes :
0
20
déc.
2007
PHP
Mantis est un logiciel libre (GPL) collaboratif de suivi de bugs (BT pour « Bug Tracker ») écrit en PHP. Victor Boctor, l'un des développeurs principaux, vient d'annoncer la version 1.1.0 du mantoptère, à l'issue d'une période de gestation, de développement et de stabilisation de 15 mois depuis septembre 2006 passant par quatre versions alpha et trois versions candidates (release candidate).

Bien que le numéro de version ne progresse que d'un .1 depuis février 2006, Mantis 1.1 apporte un grand nombre d'évolutions :
  • Inclusion de MantisConnect (une API SOAP) ;
  • Intégration Wiki (dokuwiki, mediawiki, xwiki) ;
  • Email queuing ;
  • Intégration des Gravatars ;
  • Prise en charge de DB2 ;
  • Tagging ;
  • Filtrage des permaliens ;
  • Suivi temporel ;
  • Intégration Twitter ;
  • Prise en charge du codage de caractères UTF8 ;
  • Page de configuration générique ;
  • Visualisation des derniers bugs visités ;
  • Compatibilité XHTML ;
  • RSS authentifié.
La liste des fonctionnalités est devenue très complète, avec entre autre : 68 localisations, changelog et roadmap, recherche en texte, rapports, champs personnalisés, notifications par email, flux RSS, cycle de vie éditable, sponsoring (bounties et paiements), captcha, pièces jointes avec prévisualisation, données publiques et privées, intégration LDAP et AD, prise de charge de multiples SGBDR, etc. Ce qui fait de Mantis un bug tracker qui devrait satisfaire de très nombreuses équipes de différentes tailles à moins de besoins spécifiques.

Un outil de gestion de bugs (BT pour Bug Tracker) isolé est toujours un peu pauvre, et il se révèle souvent nécessaire d'avoir une intégration avec un SCM (Source Code Management), sans avoir toutefois à passer par les solutions complètes et exhaustives de type forge (GForge, Savane, LibreSource, Qualipso, etc.). ScmBug est un outil d'intégration d'un SCM avec un BT, par exemple CVS ou Subversion avec Bugzilla ou Mantis. Il oblige à lier tout commit à un bug, ou inversement de créer un bug pour pouvoir committer, permettant ainsi une traçabilité complète et la possibilité des générer des rapports et tableaux de bord. Il s'agit d'une fonction qui devrait être à ce jour incontournable ; hélas, c'est loin d'être le cas dans les projets libres d'une manière générale.

Aller plus loin

  • # Mantis : mangez-en !

    Posté par  (site web personnel) . Évalué à 2.

    Après avoir testé 4 ou 5 gestionnaire de bug dans ma boite, on s'est arrêté sur mantis et vraiment, on en est très satisfait.

    Une mise en place assez facile, un fonctionnement intuitif, des notifications par mail, une bonne apparence visuelle, la possibilité d'avoir des commentaires privés ou publics, un bonne gestion du flux de développement (bug reporté --> assigné --> résolu --> assigné --> fermé dans notre cas, mais c'est configurable).

    On peut facilement gérer plusieurs projets, sans que ceux-ci ne se marchent sur les pieds les uns les autres.

    Je n'utilise aucun des plugins externes parce que je voulais juste un bug tracker et j'en suis très content.

  • # Hierarchie des Bugs

    Posté par  . Évalué à 1.

    Bonjour,

    A première vu Mantis ne supporte pas la hiérarchisation des bugs. Est- ce le cas ? Est-ce prévu ?

  • # Comparaison avec Trac ?

    Posté par  . Évalué à 1.

    J'utilise beaucoup Trac en le reliant à svn ( pour faire ce que fait Scmbug ). Quelqu'un a une double expérience Trac / Mantis et pourrait donner les forces/faiblesses des deux solutions l'un par rapport à l'autre ?

    ( un point que je vois tout de suite, le cycle de vie du ticket n'est pas éditable dans Trac, sauf à taper directement dans le python ).

    • [^] # Re: Comparaison avec Trac ?

      Posté par  (site web personnel) . Évalué à 2.

      Nous utilisons Mantis depuis 3 ans sur nos différents projets :
      _ C'est beaucoup plus "userfriendly" pour les néophytes en informatique. Des personnes du "métier", sans connaissance informatique, peuvent rapporter des bugs assez facilement, moyennant très peu d'explications.
      _ Le cycle de vie éditable des anomalies : c'est LA KILLER FEATURE. C'est ce cycle qui formalise le processus de dialogue entre la MOA et la MOE
      _ C'est plutôt joli avec des couleurs, et l'historique de tous les messages échangés.
      _ Et puis la 1.1 apporte l'encodage UTF-8, j'avais des soucis d'export Excel avec des caractères bizarres....

      Trac nous sert seulement de wiki sur un sous projet, c'est beaucoup moins abouti il me semble, mais aussi plus généraliste.

      • [^] # Re: Comparaison avec Trac ?

        Posté par  . Évalué à 2.

        Je confirme ce que tu écris. J'ai participé au développement d'applications de télédéclaration pour le ministère de l'Agriculture, dans une grosse SSII, et on utilise Mantis. Je l'ai trouvé pratique (couleurs pour les gravités et les états) et facile à prendre en main. Une équipe entièrement dédiée à la validation fournissait les bugs, et l'équipe de développement recevait des courriels et "n'avait plus qu'à" épurer sa page de bugs, à la suite de quoi l'équipe de validation recevait un message et pouvait retester. On avait parfois droit à quelques aller-retours avec les remarques de plusieurs intervenants et divers attachements.

        Il y avait un léger couplage avec le CVS, car dans la raison de chaque commit on incluait le numéro du bug Mantis. Pratique pour la tracabilité et ça évitait quelques doublons ou régressions.

        NB : pas « encodage UTF-8 » mais « codage UTF-8 », merci.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.