Mozilla Bugzilla 2.18 est disponible

Posté par (page perso) . Modéré par Christophe Guilloux.
Tags :
0
17
jan.
2005
Mozilla
Dave Miller a annoncé la tant attendue version majeure 2.18 de Bugzilla après deux ans et demi de développement de l'équipe internationale. Bugzilla est le système libre/opensource de traçabilité des bugs très largement déployé car utilisé par Mozilla, KDE, GNOME, RedHat, Mandrakesoft et leurs communautés respectives (plusieurs centaines de milliers de développeurs et utilisateurs). Il est écrit en Perl, est dépendant de Apache et MySQL et tourne sous Linux et Windows.

La version 2.17, branche de développement de la version 2.18 maintenant fermée, a vécu plusieurs révisions qui ont été longuement testées et validées sur bugzilla.mozilla.org, une des installations les plus grandes et les plus importantes de Bugzilla (puisqu'elle gère des produits comme Firefox, Thunderbird et la suite Mozilla). On aboutit donc à une version 2.18 particulièrement stable.

Bugzilla 2.18 est une version majeure puisqu'elle contient de nombreuses améliorations : reporting, graphiques, flags, groupes, recherche, insiders, chronométrage, authentification, localisation, visionneuse de patches, obscurcissement d'adresses mèl, et encore beaucoup d'autres améliorations.

En parallèle à la nouvelle version stable 2.18, la désormais ancienne version 2.16 a subit une révision, la 2.16.8, qui corrige un problème de sécurité, un bug et améliore la documentation. Toujours en parallèle à la maintenance des versions stables 2.18 et 2.16, la branche de développement 2.19 vient d'être ouverte et a déjà donné naissance à la 2.19.1 et 2.19.2 à des fins de tests et développement : cette dernière version apporte la même correction de sécurité que la 2.16.8 et quelques améliorations. La branche 2.19 devrait entrer en gel en mars, pour une version stable 2.20 en avril.

En septembre 2005, on devrait voir geler la version de développement 2.21 pour aboutir à la version stable 2.22 en octobre. Cette sortie correspondra à la fin de support de la version 2.16.

Vous pourrez trouver une liste d'installations Bugzilla publiques ainsi que des démos de différentes versions.
  • # Autre produit sympa

    Posté par (page perso) . Évalué à  4 .

    A noter, ce produit pour gérer les tâches, leurs affectations et les temps associés : http://dev.mysql.com/downloads/other/eventum/(...)

    Développé par MySQL, sympa avec de beaux graphiques... on l'utilise dans notre société pour gérer la production.

    http://about.me/straumat

    • [^] # Re: Autre produit sympa

      Posté par Anonyme . Évalué à  2 .

      Bonjour,

      Si tu as le temps de nous en dire un petit peu plus, je suis preneur.

      En effet je cherche un tel outil pour gérer des petits projets, avec les tâches, le temps passé, la gestion des anomalies, qu'il soit si possible en français (ça serait un plus mais pas une obligation), et que la partie visuelle dans le navigateur soit conforme aux standards du web (XHTML).

      Merci !
      • [^] # Re: Autre produit sympa

        Posté par (page perso) . Évalué à  1 .

        Bonjour,

        Et bien, ce projet te permet de définir des projets et de définir différents aspets: nom des catégories, worlfow...

        Ensuite, tu dis quelles personnes participent et quels clients... puis tu crées des tâches, et tu les affectes à une ou plusieurs personnes...
        Ceci étant fait, tu as encuite un suivi de qui a fait koi sur quelle tâche et combien de temps cela a pris..
        tu as de bonnes éditions de de beaux camenberts..

        la finition du produit est excellente !!
        a+
        Stéphane

        http://about.me/straumat

  • # Trop gros ?

    Posté par (page perso) . Évalué à  10 .

    J'avais regarde bugzilla comme gestionnaire de bug et todo list pour ma societe, mais j'ai laisse tombe. Le probleme, c'est que c'est calibre uniquement pour des tres gros projets. Il y a pas moyen d'en faire un petit gestionnaire de bug. Parmi les trucs que je voulais enlever:
    - moins de statuts sur un bug: ouvert ou ferme, ca suffit
    - moins de niveaux de gravite
    - moins de declinaison produit / sous-produit / version
    - interface plus simple

    Finalement, j'ai opte pour roundup (http://roundup.sf.net(...)) et je ne regrette pas. Super simple a mettre en place (3 minutes) , communaute tres active et tres reactive, suivi complets des bugs par email, independant de la base de donnee, ...

    Par contre, je ne sais pas si il suivrai la montee en charge de bugzilla. Mais je m'en fous, on ne sera jamais plus de 50 a l'utiliser.
    • [^] # Re: Trop gros ?

      Posté par (page perso) . Évalué à  7 .

      Les status/resolution ne sont pas modifiables car ils font partie du workflow.
      Le nombre de niveaux de gravité ("sévérité") peut être réduit par localconfig (de même pour plateforme et OS).

      La déclinaison produit/composant n'est qu'à deux niveaux, la version se rattache à au produit. À noter, le niveau de hiérarchisation supérieur "département" dans les versions futures (2.20 il me semble à moins que ce ne soit 2.22), ce qui donne département>produit>composant, je ne sais pas si ce niveau est débrayable/optionnel.

      Pour ce qui est de la complexité de l'interface, il y a un bon nombre de fonctionnalités que tu peux enlever : target milestone, status whitebord, watcher, etc.

      Sinon, encore une autre alternative, simple et belle et libre : Mantis : http://www.mantisbt.org/(...)
      • [^] # Re: Trop gros ?

        Posté par . Évalué à  3 .

        Les status/resolution ne sont pas modifiables car ils font partie du workflow.

        Modifiables, non, mais certains peuvent être éliminés (le statut UNCONFIRMED est desactivé par défaut, l'utilisation de VERIFIE D est facultatif, etc...)

        Pour ce qui est de la complexité de l'interface, il y a un bon nombre de fonctionnalités que tu peux enlever : target milestone, status whitebord, watcher, etc.

        Je conseille en général aux personnes qui veulent se mettre à Bugzilla de :

        1) desactiver toutes les fonctionalités dont ils n'ont pas besoin
        2) commenter dans les templates html tout ce qui ne les interesse pas

        Le seul choix indispensable qui est vide par défaut est le champ "Summary". On peut donc enlever toutes les questions posées au rapporteur sauf celle-ci.
        • [^] # Re: Trop gros ?

          Posté par (page perso) . Évalué à  1 .

          Modifiables, non, mais certains peuvent être éliminés (le statut UNCONFIRMED est desactivé par défaut, l'utilisation de VERIFIE D est facultatif, etc...)


          Le Statut VERIFED, c'est mon préféré lorsque j'ai vérifié que les devs ont bien fait leur boulot et que leur correction est validée ;-)
    • [^] # Re: Trop gros ?

      Posté par . Évalué à  3 .

      Pour mes petits projets, j'utilise de mon coté trac (http://www.edgewall.com/trac/(...)).
      Qui intègre aussi un Wiki et offre une interface à subversion.
      Une interface simple et assez pratique.
      Un bémol pour certains : fonctionne avec un CGI python et nécessite donc que mod_python soit installé.
      • [^] # Re: Trop gros ?

        Posté par . Évalué à  3 .

        trac est en effet très très bien. Combiné a subversion il a d'ailleurs fait l'unanimité des personnes avec lesquels je l'utilise pour gérer des projets de fac. Simple et efficasse, bref l'outil qui ne fait que gagner du temps.

        La gestion des bugs me semble quand même être son point noir. Autant la création de bug est bien faite, et les catégories simplement configurables. Autant la naviguation dans les bugs n'est pas ergonomique pour un sou. Il n'y a pas moyen de remonter d'un niveau dans la hierarchie. Par exemple si tu regardes les bugs, que tu en changes un, si tu reviens en arrière cela va poser problème, et il n'y a pas de lien pour retourner dans la catégorie que tu observais; il faut repartir du début... pas glop

        Ca peut vite devenir génant si tu utilises trac uniquement pour l'aspect gestion de tickets
    • [^] # Re: Trop gros ?

      Posté par (page perso) . Évalué à  2 .

      Dans la série "j'ai des besoins modestes et je veux pas enculer une mouche avec une bate", il y a flyspray (http://flyspray.rocks.cc(...)) qui mériterait à être un peu plus connu.

      La liste des bugs s'affiche en première page, ce qui est tout de même plus intuitif (notamment pour les non informaticiens qui ne raisonnent pas forcément en terme de requêtes SQL).
    • [^] # Re: Trop gros ?

      Posté par . Évalué à  1 .

      Bugzilla trop gros ? On voit que tu n'as jamais essayé (veinard) certains logiciels de suivi de bugs proprio, comme TeamTrack ou ClearQuest. Là, tu saurais ce que c'est, un système de suivi vraiment lourd. Je peux t'assurer qu'après avoir utilisé ces derniers, Bugzilla fait figure de gazelle :-)

      Enfin bref tout est relatif comme disait le vieux moustachu.
    • [^] # Re: Trop gros ?

      Posté par (page perso) . Évalué à  1 .

      J'utilise roundup également, sa particularité est qu'il est personalisable à l'extrème, c'est un vrai bijou ! On peut en faire une simple todo-liste jusqu'à une gestion complète de projets par clients avec gestion des délais, du budget etc... (voir le wiki pour des exemples)

      L'autre particularité c'est que le bug-tracking de roundup n'utilise pas roundup (mais celui de sf) !
  • # Bugzilla

    Posté par . Évalué à  6 .

    > Il est écrit en Perl, est dépendant de Apache et MySQL

    Marche aussi en cgi. Donc il ne dépend pas d'Apache.
    Red Hat utilise Bugzilla avec PostgreSQL. Il y a aussi une version pour Oracle :
    http://bugzilla.redhat.com/download/(...)

    > et tourne sous Linux et Windows

    Et sûrement tous ce qui supporte perl, donc les *BSD, Unix, etc.

    > a vécu plusieurs révisions qui ont été longuement testées et validées sur bugzilla.mozilla.org, une des installations les plus grandes et les plus importantes de Bugzilla

    Bugzilla de test (ici 2.18-rc3) est aussi utilisé chez Red Hat (en test depuis plusieurs mois) :
    https://bugzilla.redhat.com/beta/(...)
    (Voir aussi http://bugzilla.redhat.com/(...) "Bugzilla news").
    • [^] # Re: Bugzilla

      Posté par (page perso) . Évalué à  1 .

      j'ai installé la version Postgres : c'est bien mais ce n'est pas localisé en français (et ils ont forcémen t quelques versions de retard). Le support Postgres que j'attendais pour la version 2.18 n'arrivera quant à lui que dans la v2.22 !

      Donc Postgres ou Francais, il faut choisir ...
  • # Comment c'est possible ?

    Posté par . Évalué à  4 .

    Je suppose qu'on suit le développement de Bugzilla avec un Bugzilla. Or si ce Bugzilla est bogué, ça va forcément faire boguer le Bugzilla à déboguer.
    • [^] # Re: Comment c'est possible ?

      Posté par . Évalué à  3 .

      C'est pa le même problème pour les compilateurs?? Tu t'es jamais posé la question?
      Et qu'est ce qui était là avant : le code compilé ou le compilateur?

      Que des questions philosophiques....
      • [^] # Re: Comment c'est possible ?

        Posté par . Évalué à  0 .

        la poule!

        je pouvais pas resister!!

        -->[]
      • [^] # Re: Comment c'est possible ?

        Posté par (page perso) . Évalué à  2 .

        Pareil pour les OS, les éditeurs de textes, et j'en passe ...
      • [^] # Re: Comment c'est possible ?

        Posté par (page perso) . Évalué à  4 .

        ni l'un ni l'autre, le premier arrivé c'est le code assembleur de bootstrap si je me souviens bien.
        grosso modo tu écris un mini compilateur en langage machine. Puis tu te sers de ton mini compilateur pour compiler ton compilateur, jusqu'à ce que celui-ci atteigne le stade de "self-hosting", c'est-à-dire qu'il soit capable de se compiler lui-même.
        Just my 2¢
        • [^] # Re: Comment c'est possible ?

          Posté par . Évalué à  1 .

          merci mais c'était pas la peine....

          Et pour le message au dessus, c'était evidemment un analogie à l'oeuf et la poule.
      • [^] # Re: Comment c'est possible ?

        Posté par . Évalué à  1 .

        En fait pour Bugzilla c'est simple :
        Ils ont juste fait un Bugzilla 0.1 avec zéro bugs.
        Du coup pas besoin de Bugzilla pour le développer
        Un peu comme une poule sortie de terre en somme
      • [^] # Re: Comment c'est possible ?

        Posté par (page perso) . Évalué à  1 .

        Allez pour mémoire relisez l'article d'ACM 85 de Ken Thompson sur la problématique de sécurité du code d'un compilateur compilé par lui-même.

        Comme ça, ça fera encore plus de questions philosophiques ;-)
  • # Spam...

    Posté par . Évalué à  2 .

    obscurcissement d'adresses mèl


    Eh bien, il était temps... je ne fasais plus de rapport de bug sur le bugzilla de mozilla à cause de cela... marre du spam...
    • [^] # Re: Spam...

      Posté par . Évalué à  4 .

      En plus vu le spam ciblé, tu ne devais recevoir que des pubs pour des logiciels buggés.

      -->[]
    • [^] # Re: Spam...

      Posté par (page perso) . Évalué à  2 .

      Je ne sais pas exactement quelle version de bugzilla ils utilisent chez KDE, mais ça fait déjà longtemps que les adresse mail n'apparaissent que quand on est identifié, et qu'elle sont obscurcie dans les courriers électroniques.

Suivre le flux des commentaires

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