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.
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
- Le site de Bugzilla (7 clics)
- La page des statuts (1 clic)
- L'avis de sécurité (1 clic)
- Nouvelles fonctionnalités de la 2.20 (3 clics)
- Téléchargement (2 clics)
- DLFP : Derrière vos distributions et logiciels favoris... le retour (1 clic)
# Communication entre les système de traques de bugs
Posté par Mjules (site web personnel) . Évalué à 5.
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
[^] # Re: Communication entre les système de traques de bugs
Posté par _PinG _ . Évalué à 4.
[1] https://wiki.launchpad.canonical.com/Malone(...)
[^] # Re: Communication entre les système de traques de bugs
Posté par Nÿco (site web personnel) . Évalué à 1.
Mais tu as raison, il faudrait sans doute penser à un format ouvert et standard de rapports de bugs.
# mail
Posté par M . Évalué à 3.
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 tuiu pol . Évalué à 3.
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 Gof (site web personnel) . Évalué à 4.
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 tgl . Évalué à 4.
http://search.cpan.org/~mcvella/WWW-Bugzilla-0.5/Bugzilla.pm(...)
[^] # Re: mail
Posté par yoho (site web personnel) . Évalué à 2.
[^] # Re: mail
Posté par Philippe F (site web personnel) . Évalué à 1.
# Autres systèmes ?
Posté par thecat . Évalué à 1.
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.
[^] # Re: Autres systèmes ?
Posté par Xavier Teyssier (site web personnel) . Évalué à 1.
Mon cahier des charges semble assez semblable au tien : un truc simple.
Je l'ai aperçu en utilisation chez OVH (http://travaux.ovh.net/),(...) et depuis je commence à l'essayer pour mes besoins perso.Ca m'a l'air pas mal. Reste à approfondir la chose...
[^] # Re: Autres systèmes ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
Petit, leger, parfait pour les petites faims. Facile a installer, facile a bidouiller, facile a utiliser. Tout ce qu'il faut.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.