Sortie de Bugzilla 2.20 (et 2.21.1 et 2.18.4)

Posté par . Modéré par Sylvain Rampacek.
Tags :
0
2
oct.
2005
Mozilla
Bugzilla, l'un des projets Open-Source de système de suivi et de gestion d'anomalies (bug tracking system) le plus répandu, sort en même temps la première version de sa branche stable 2.20, la première version de sa branche de développement 2.21 et une version de correction de l'ancienne branche stable 2.18. Aucune sortie n'est prévue pour l'ancienne branche stable 2.16 toujours maintenue.

Ces trois versions corrigent des vulnérabilités présentes dans toutes les branches 2.18 à 2.21 de Bugzilla (voir la page sur les avis de sécurité).

Voir les changements apportés par ces versions dans les changelogs ci-dessous.

Quelques autres nouvelles :
  • La branche 2.16 entame sa dernière ligne droite et sera abandonnée à la sortie de la 2.22. L'équipe a verrouillé cette branche et seuls les bogues de sécurité seront désormais corrigés. Il est fortement recommandé aux administrateurs de migrer en 2.20.
  • La branche 2.22 doit être gelée deux semaines après la sortie de la 2.21.1. La première version officielle est prévue trois mois après le gel de la 2.22 (c'est-à-dire rendez-vous en janvier).
  • Oracle travaille en collaboration avec Bugzilla pour un support complet de la base propriétaire Oracle avec Bugzilla (ce qui serait le sésame pour mettre un pied dans beaucoup de sociétés pour qui base de données signifie forcément - et uniquement - « Oracle »). Dans l'idéal ce support sera opérationnel pour Bugzilla 2.24.
Les changelogs de chaque version :
2.20
La version 2.20 est une version majeure pour Bugzilla.
Il est à signaler que - pour une fois - bugzilla.mozilla.org n'a pas testé cette version avant sa sortie, en effet la Fondation a, semble-t-il, eu trop à faire pour effectuer cette mise à jour.

* Support (expérimental) de PostgreSQL. Il est noté que le support est "acceptable" mais contient sans doute encore quelques bogues. Il est donc conseillé de le laisser mûrir. En outre, un script de migration des données entre un Bugzilla MySQL et un Bugzilla PostgreSQL est proposé (à version de Bugzilla équivalent).
* Nouvelle interface utilisateur. C'est un premier pas vers l'interface prévue pour la future version 2.22.
* Nouvelle catégorie au-dessus de "Product". Il est désormais possible de grouper les "productions" en "classifications".
* Rapports par courriel des résultats de requêtes automatiques.
* Méthode d'authentification par variable d'environnement. Bugzilla peut désormais accepter des valeurs passées par Apache comme méthode d'authentification.
* Gestion des sauts de ligne côté serveur. Les lignes des commentaires étaient auparavant coupées à 80 caractères et stockées ainsi dans la base. Maintenant Bugzilla enregistre les commentaires tel quels et les traite lors de l'affichage.
* Interface utilisateur pour l'édition des priorités, OS, plateformes et sévérités.
* Les requêtes sont désormais valides RSS 1.0
* Choix de la méthode d'envoi des courriels. On a maintenant le choix entre sendmail, SMTP, qmail ou via des fichiers.
* Modifications des préférences des utilisateurs.
* Stockage des gros fichiers. Il est maintenant possible de conserver les gros fichiers sur le disque plutôt que dans la base.
* Marquer un fichier attaché comme obsolète va automatiquement annuler toutes les requêtes pour ce fichier.
* Il est possible de voir quels sont les utilisateurs qui vous "regardent" dans la page de préférences des courriels.
* Vous pouvez dire à Bugzilla de marquer certains commentaires dans une couleur différente.
* "QA Contact" apparaît aussi dans la page des nouveaux bogues (si l'option est choisie dans votre installation)
* Les courriels de Bugzilla ont maintenant un champ "In-Reply-To" qui permettra, si votre client de courriel le supporte, de visualiser les courriels sous forme de fils de discussion
* Il est possible de nier des champs booléens dans la page de recherche avancée.
* Vous pouvez ajouter les mots %assignee%, %reporter%, %user% (vous-même) ou %qacontact% en terme de recherche à côté d'un booléen.
* Il est également possible d'effectuer des recherches par "commenter"
* Si un groupe n'a pas de nom il sera renommé par "group_#" avec "#" l'identifiant groupe de Bugzilla pour ce groupe.
* Un rapport du temps passé par bug est maintenant disponible.

2.21.1
La branche 2.21 de Bugzilla est la branche de développement devant aboutir à la version 2.22.
Une réorganisation du code a été effectuée afin de rendre le programme plus facile à adapter aux besoins du clients.
Je vous laisse découvrir ce qu'apporte cette version dans la page de statut.

2.18.4
En plus de corriger les vulnérabilités, cette versions corrige quelques bogues.
Cette version est la dernière de cette branche dans laquelle sont corrigés des bogues non critiques. Toutes les futures versions de la branche 2.18 corrigeront seulement des vulnérabilités ou des bogues importants.

Quelques autres projets de suivi et de gestion d'anomalie libres :
* Mantis http://www.mantisbt.org/
* Roundup http://roundup.sourceforge.net/index.html
* Trac http://www.edgewall.com/trac/
* Flyspray http://flyspray.rocks.cc/
* Whups (du projet Horde) http://www.horde.org/whups/
* Otrs http://otrs.org/
* RT http://www.bestpractical.com/rt/

Aller plus loin

  • # Communication entre les système de traques de bugs

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

    Il y a quelques temps, j'ai lu qu'un problème des distributions, c'était que les bugtrackers ne communiquaient pas entre eux.

    Les mainteneurs des paquets de distributions reçoivent les bugs des utilisateurs et doivent ensuite les remonter à la source. L'ennui c'est qu'il n'y pas de système permettant d'envoyer directement le rapport sur le bugtracker du projet source, il faut "au mieux" ajouter un commentaire dans un bug existant (après l'avoir trouvé) ou "au pire" écrire carrément un nouveau rapport.
    Avec un système permettant d'envoyer le contenu complet du bug sur un autre bugtracker, les mainteneurs gagneraient du temps et plus de bugs seraient remontés (on peut même imaginer qu'en vérifiant automatiquement sur les bugtracker des autres distros, le bug soit confirmé plus facilement).


    Arrive maintenant ma question, je n'ai rien vu de tel dans les releases notes de la version qui vient de sortir mais est ce que ça existe ? est ce que c'est en projet ?

    Merci
  • # mail

    Posté par . Évalué à 3.

    L'un des problemes de bugzilla, c'est qu'il faut forcement passé par l'interface web pour repondre aux bugreports.

    Or certains developpeurs prefereraient avoir plutot le comportement d'une ML et non passer leur temps dans l'interface web.

    Vous connaisez des systèmes de suivi qui ont ce comportement ?

    Le bugzilla de debian a un peu ce comportement, mais je sais pas s'il est facilement exploitable par d'autres projets.
    • [^] # Re: mail

      Posté par . Évalué à 3.

      Bah le pire c'est que vu le fonctionnement de Bugzilla, qui permet de revevoir un mail à chaques changements des bugs suivis, il doit être possible d'ajouter aussi une gestion des mails "entrants"..

      Moi je suis pressé de voir arriver le support Oracle, comme ça cela fera taire tous les pénibles que je croise et qui l'éliminent parce qu'il n'utilise que les bases Libres.
      • [^] # Re: mail

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

        le bugzilla de KDE le permet.
        12345@bugs.kde.org ajoute un commentaire au bug 12345
        et 12345-done@bugs.kde.org ferme le bug 12345

        Je ne sais pas à quel point le bugzilla de KDE est modifié
    • [^] # Re: mail

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

      Avec roundup, tu as un mode ou tu peux traiter les mails entrants comme des rapports de bugs. Cela dit, j'ai pas installe cette partie-la.
  • # Autres systèmes ?

    Posté par . Évalué à 1.

    Quelqu'un connaitrait (et aurait des retours d'expèriences sur) d'autres "bug tracking système" un peu moins lourd?
    Par "moins lourd" je veut surtout dire plus simple, moins complet voir mème trés basique.
    Bugzilla c'est peut-etres génial mais vraiment trop usine a gaz pour mes petit besoins.

Suivre le flux des commentaires

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