Bugzilla est un outil de suivi qui peut être utilisé dans toute organisation formelle ou informelle de développement logiciel bien évidemment, mais aussi dans de nombreux cas de support et helpdesk par exemple, ou encore dans le cadre de l'administration, la gestion du changement et le suivi de production pour les systèmes et les bases de données, ou bien plus généralement toute organisation nécessitant une centralisation, structuration, communication, traçabilité et reporting de son évolution.
Pour rappel, Bugzilla est écrit en Perl, et placé sous tri-licence MPL+GPL+LGPL. Côté historique, il est issu de la libération de Netscape en 1998 (alors en version 2.0), a bénéficié d'un développement continu et permanent (version mineures stables paires, 2.18, 2.20, 2.22) et a suivi de près les projets Mozilla, puisque Bugzilla est en intégration continue sur le système de suivi de bugs de la fondation Mozilla.
Au chapitre des nouveautés de la version 3.0 de Bugzilla, on a entre autre :
- champs personnalisés ;
- prise en charge de mod_perl ;
- recherches sauvées partagées ;
- pièces jointes et drapeaux sur les nouveaux tickets ;
- résolutions personnalisées ;
- permission par produits ;
- améliorations de l'interface utilisateur ;
- interface XML-RPC ;
- thèmes (skins) ;
- meilleure prise en charge de l'UTF-8 ;
- possibilité de créer et modifier des bugs par courriel ;
- et bien d'autres...
Sachez que Bugzilla est très largement adopté par le monde du logiciel libre et par l'industrie et, outre l'assistance assurée par l'équipe de développement et les contributeurs, nombre de sociétés proposent des services d'assistance payants.
Aller plus loin
- Bugzilla (2 clics)
- Nouveautés (2 clics)
# XML-RPC !
Posté par ploum (site web personnel, Mastodon) . Évalué à 4.
Mes livres CC By-SA : https://ploum.net/livres.html
# Rien à voir, quoique
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
J'arrête Linux demain !
Bravo Nÿco, n'arrête pas linuxfr.
[^] # Re: Rien à voir, quoique
Posté par j (site web personnel) . Évalué à 1.
[^] # Re: Rien à voir, quoique
Posté par Sytoka Modon (site web personnel) . Évalué à 1.
http://linuxfr.org/~Nyco/comments,139.html
[^] # Re: Rien à voir, quoique
Posté par j (site web personnel) . Évalué à 0.
d'ailleurs en 1999 DLFP était motorisé par DaCode
# No more perl
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
Les raisons qu'il donne en bref : perl, ça sux par rapport aux "nouveaux" langages. Les raisons en plus détaillés (de l'avis de l'auteur, pas du mien hein, je connais pas trop perl) :
- du code en perl est plus difficile à revoir et à maintenir, du fait qu'il y a "plusieurs façon de faire la même chose", dont certaines sont moins propres que d'autres, ce qui donne du code crade parfois), et du fait c'est plus dure à lire : instructions peu verbeuses et souvent réduites à des caractères cabalistiques
- pas de design par contract
- pas de vrai système d'exceptions
- gourmandise de mod_perl en terme de ressource
- erreurs du compilateur perl souvent peu explicites
Bref, ils réfléchissent à une migration vers Python, Ruby ou un autre langage. Rien n'est décidé, peut être même que ça ne se fera pas (dur de migrer un si gros projet d'un langage à un autre).
[^] # Re: No more perl
Posté par pomperoi . Évalué à 4.
[^] # Re: No more perl
Posté par Gonéri Le Bouder (Mastodon) . Évalué à 5.
http://perl.apache.org/docs/2.0/user/handlers/intro.html
C'est quoi exactement ?
Pour les exceptions, c'est prévu dans Perl6.
Enfin, par rapport aux critiques récurantes par rapport à la lisibilité du code, je pense que c'est un faux argument. C'est, a mon avis, d'avantage un problème de norme de codage au sein du projet.
[^] # Re: No more perl
Posté par reno . Évalué à 1.
> C'est quoi exactement ?
http://fr.wikipedia.org/wiki/Programmation_par_contrat
Sinon, personnellement je pense le contraire pour la lisibilité: je trouve Perl très mauvais de ce point de vue (et Perl6 a part être plus baroque ne changera pas grand chose de ce point de vue).
Ruby ou Python sont bien meilleur sur ce point la..
[^] # Re: No more perl
Posté par pomperoi . Évalué à 2.
D'autre part, Perl 6 sera au contraire beaucoup moins baroque que Perl 5. Tout ce qui rend Perl 5 difficile à manier -- à savoir le nombre important d'exceptions et de cas particuliers dans les syntaxes -- a été éliminé au profit de règles plus simples, et générales, donnant ainsi plus d'homogénéité au langage.
[^] # Re: No more perl
Posté par Bozo_le_clown . Évalué à 9.
#!/usr/bin/perl $;="@{'`|;{'^'!.|-'}";$.++;$.++;$.++;$_="(.)?";/((?{$_.=$_}).)+$/;@_='~!@#$%^&*( )_+`-=[]\\{}|;\':",./<>? '=~/$_/;@_ _=$;=~/$_/;$_="(.)*?";/((?{$_.=$_}).)+$/;$Z-= $Z;"$.$."-$Z;/((?{$_ _[$z]&&!("${_[$x]}"^"${_[$y]}"^"${_ _[$z]}"^"$Z")&&($a.=$_[$x ],$b.=$_[$y],$z++);$x++;$y+=!($x%="$.$.");$y%="$.$.";}).)+/;$_="^"^"^";$_ _=".>.\ '$_ _ _$b')".".('!\@/\"'^'}.')".']}`';De quel nationalité es tu ? :)[^] # Re: No more perl
Posté par CrEv (site web personnel) . Évalué à 4.
A quand un Obfuscated C contest ? y'a quand même moyen de faire des choses bien bien crade aussi, surtout avec les pointeurs... ;-)
[^] # Re: No more perl
Posté par Moonz . Évalué à 4.
[^] # Re: No more perl
Posté par Gonéri Le Bouder (Mastodon) . Évalué à 1.
[^] # Re: No more perl
Posté par pomperoi . Évalué à 5.
Quant à la rigueur, c'est bien plus du côté du cerveau du développeur que ça se passe. Aucun langage n'a jamais empêché des programmeurs inexpérimentés de commettre des plats de spaghetti que je sache. Il est vrai que les langages fortement typés à la Ada ou C++ ont des compilateurs qui imposent bien plus de contraintes. D'autre part, les langages à inférence de type à la Haskell permettent au programmeur de se reposer sur l'intelligence du compilateur. Cependant, Perl, Ruby et Python sont exactement similaires sur ce point, car ils partagent les mêmes caractéristiques: typage dynamique, et possibilité de modifier le programme à l'execution, notamment. Le reste est une pure question de goût.
[^] # Re: No more perl
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Un truc super en perl c'est qu'une variable scalaire commence par un $. Cela, c'est vachement bien de séparer les variables des mots clefs.
Comme il a été dis, en perl6, ils ont éliminé pas mal de truc pas propre mais il est possible déjà de faire propre en perl5. Il suffit d'utiliser les bons modules.
Enfin, un gros avantages du perl, les programmes que j'ai fait il y a 10 ans en perl5_004 marche toujours tel quel !
Bref, il est de bon ton de critiquer perl de nos jours, surtout sur dlfp, notamment pour pousser vers python. Quand je vois dans une debian le nombre de version de python et les incompatibilités entre elles, personnellement, je n'ai pas envie d'en faire.
[^] # Re: No more perl
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
>> ces languages imposent d'avantage de rigueur et de normalisation dans la façon de coder.
> C'est faux. La normalisation n'est pas imposée par un langage, mais par ensemble de règles
Je ne sais pas pour ruby, mais essayes de faire du code mal indenté en Python, et reviens discuter après si tu penses toujours que la normalisation n'est pas imposée par le language dans ce cas ...
[^] # Re: No more perl
Posté par pomperoi . Évalué à 1.
[^] # Re: No more perl
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
[ ] vrai
[ ] faux
?
[^] # Re: No more perl
Posté par Moonz . Évalué à 3.
Par exemple, si tu prends l'indentation comme étant une règle de codage et impose "il faut le faire" (parce qu'on pourrait aussi imposer de ne pas le faire, imposer une tabulation, imposer deux espaces,... ce que python n'impose pas), oui
Maintenant, je te donne une nouvelle règle: "il faut délimiter le code d'une fonction par des accolades" ou "toute instruction se termine d'un point virgule". Alors:
Le langage C impose des règles de codage:
[ ] vrai
[ ] faux
[^] # Re: No more perl
Posté par Guillaume Rousse (site web personnel) . Évalué à 1.
[^] # Re: No more perl
Posté par Sebastien (site web personnel) . Évalué à 3.
C'est ce qui se dit, mais au final, on peut faire du code crade quelque soit le langage (et c'est d'autant plus ironique si quelqu'un souhaite vendre du PHP sur cet argument).
> - pas de design par contract
Quelle vaste blague! Rares sont les langages implémentant réellement du DbC. Non, du typage fort n'est pas suffisant pour se dire DbC. Non, avoir une macro "assert" n'est pas suffisant pour se dire DbC.
> - pas de vrai système d'exceptions
Les exceptions sont un modèle de gestion des erreurs. Se baser là-dessus pour juger un langage ou environnement est naïf. Java sait gérer les exceptions, mais ça n'empêche pas celles-ci d'arriver à l'utilisateur ou d'en dégoûter plus d'un avec une stacktrace énorme.
> - gourmandise de mod_perl en terme de ressource
Le principal problème est que mod_perl n'est pas mutualisable. Pour le reste, il apporte des avantages dont il faut profiter et des contraintes dont il faut tenir compte.
> - erreurs du compilateur perl souvent peu explicites
C'est le cas de bien des langages. Jusqu'à présent, le seul qui me fasse dire le contraire, pour le peu que je l'ai pratiqué, c'est Ada.
# Interêt de GPL + LGPL?
Posté par ocroquette . Évalué à 2.
[^] # Re: Interêt de GPL + LGPL?
Posté par CrEv (site web personnel) . Évalué à 3.
[^] # Re: Interêt de GPL + LGPL?
Posté par imalip . Évalué à 2.
Donc effectivement, ca fait doublon, vu que la LGPL est d'office une double licence GPL/LGPL.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.