Il est né le 23 avril 2002 à 10:23. Il était pas bien gros à la naissance, mais déjà on lui en voulais un peu. D'année est année, il s'est fait de plus en plus haïr. Mais bon, malgré cela on peu quand même fêter les 4 ans du bug #41514 (http://bugs.kde.org/show_bug.cgi?id=41514 )
Saleté de bestiole va ! J'espère cruellement que son espérance de vie ne sera pas trop longue.
Plus sérieusement, ce BUG fait que Kmail se bloque quand il filtre les messages entrant via un filtre externe (spamassassin,....). Quand comme moi, vous recevez plusieurs dixaines de spams par jour et que vous vérifiez vos mails régulièrement, c'est très très pénible. On écrit un mail, et puis tout un coup plus rien ne répond, plus rien ne s'écrit, et là on se dit : "p***in de kmail !!!"
Ce bug est celui qui a recueilli le plus de vote, et en 4 ans aucune solution n'a été apporté. Alors bien sûr on peut toujours dire que l'on peut mettre en place un serveur de mail qui va récupérer les mails chez notre FAI, et faire tourner l'antispam dessus. Il ne reste plus alors qu'à faire en sorte que kmail récupère les mails dans la boite en local. Mais bon, je rappel quand même le but de KDE, qui est d'offrir une interface simple à l'utilisateur, et mettre en place un serveur de mail pour pouvoir bénéficier confortablement d'un filtre anti-spam, c'est quand même pas user friendly.
On lit souvent que l'un des avantages du libre est que les bugs sont corrigés plus rapidement. La preuve en est que c'est faux. Dans le libre les bugs sont potentiellement corrigé plus rapidement. Mais faut il encore que la tâche ne soit pas trop importante et que quelqu'un veuille bien s'y mettre.
Journal Joyeux anniversaire au #41514
24
avr.
2006
# Tout reprendre ?
Posté par Ludovic F (site web personnel) . Évalué à 1.
A mon avis, le bug est lié à la structure du code, qui impose sans doute de recoder tout ou une partie de la partie filtrage / relève du courrier qui ne doit pas motiver des foules de développeurs.
Il va falloir attendre qu'une bonne âme s'y intéresse plus sérieusement :)
# Bon anniversaire ...
Posté par yannig (site web personnel) . Évalué à 2.
Tient, juste au passage, il ne s'agit pas d'un bug (le programme fonctionne très bien, il met juste 3 plombes à répondre) mais d'un désagrément pour l'utilisateur. Là dessus, il faut également se poser la question du travail à fournir pour faire ce changement (gestion filtre et relevé des messages etc). Là tout d'un coup, je comprends beaucoup mieux pourquoi tout le monde s'en fout :)
[^] # Re: Bon anniversaire ...
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
Dans le même genre, la raison pour laquelle je n'utilise pas sylpheed depuis des années c'est que l'interface freeze pendant qu'il synchronise l'IMAP, et c'est très lourd quand ca arrive pendant que tu l'utilise et que ton serveur IMAP met un peu de temps avec tes 10k mails par dossier.
[^] # Re: Bon anniversaire ...
Posté par Boke Bocadillo (site web personnel) . Évalué à 1.
[^] # Re: Bon anniversaire ...
Posté par Colin Leroy (site web personnel) . Évalué à 4.
(j'ajouterai même qu'il n'est pas sujet au bug #41514 de kmail, mais ça se verrait trop).
[^] # Re: Bon anniversaire ...
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
J'ai suivi le changelog à une époque en espérant que ca soit un jour corrigé et puis j'avais abandonné l'idée :-)
[^] # Re: Bon anniversaire ...
Posté par tene . Évalué à 1.
Pas d'accord, c'est un bug, le logiciel ne se comporte pas comme on s'y attendrait. Un point c'est tout.
Si tous les créateurs de logiciel (libre ou non) pouvait simplement partir de là, on aurait sans doute des logiciels avec moins de problèmes, moins lent et moins gourmant en mémoire.
Bref c'tait mon coup de gueule du matin... comment ça il est 1h :p
# Grrr
Posté par kolter (site web personnel, Mastodon) . Évalué à 0.
ce qui m'insuporte c'est ça, si tu n'es pas content :
1 - tu te plonges dans le code (bcp le font, même s'il ne sont pas programeurs à la base)
2 - tu change de client (gnus, mutt, TB, sylpheed*, etc ...)
3 - tu test des alternatives à spamassasin
4 - tu propose un bounty pour la correction du bug (et oui les devs sont pas à ton service, c'est aussi ça le LL, payer pour une fonctionalité...)
à noté que j'utilise kmail avec une 30 aine de filtres et avec BOGOFILTER et que je n'ai pas à me plaindre de ça ....
M.
[^] # Re: Grrr
Posté par manatlan (site web personnel) . Évalué à -2.
<mode_balo>
Mais il y a encore des gens qui utilisent des clients lourds pour leurs mails ?! d'ailleurs on ne doit plus utiliser mails, mais gmails comme terme non ? ;-)
</mode_balo>
[^] # Re: Grrr
Posté par Matthieu Duchemin (site web personnel) . Évalué à 5.
- le problème ne viens pas de spamassassin. ça vient de la gestion des filtres externes, c'est à dire quand tu filtres tes messages par l'intermédiaire d'une application. Spamassassin n'est qu'un exemple (et aussi mon expérience), mais le problème existe aussi avec bogofilter, clamav...
- j'ai essayé de trouver une alternative, mais aucune ne me convient, car aucune n'est correctement intégré à KDE.
Mon journal soulève avant tout le problème du libre quand personne ne veut s'atteler à une tâche (je ne fait pas une critique, mais je constate qu'il y a un problème illustré par un bug qui existe depuis 4 ans). La pluspart du temps, les dev en LL font ce qu'ils on envie. Mais quand on crée un projet de la taille de KDE, que l'on souhaite amener ce projet à un niveau "professionnel" (c'est à dire qu'il puisse être utilisé dans des entreprises ou par des particuliers avec un niveau similaire aux autres solutions plus "classique"), ça peut porter préjudice à la qualité de l'offre que l'on propose.
Alors oui, je pourrais me plonger dans le code source de kmail et corriger le problème (si jamais j'y arrive). Mais le simple utilisateur (ma mère ou ma soueur par ex), il doit se taire quand il trouve un problème? On doit lui répondre systématiquement : "Si t'es pas content t'as qu'à le coder toi même".
Parfois on a l'impression que si tu n'es pas developpement, tu n'as pas le droit d'être critique. Est ce que j'ai le droit d'utiliser des logiciels libres et n'être que simple utilisateur?
Pour moi la communauté rassemble des développeurs, des contributeurs et des utilisateurs. Dans cette communauté, les développeurs mettent à disposition au reste de la communauté, leurs compétances en programation à travers les logiciels qu'ils développent. Les contributeurs eux, mettent à disposition leur savoir faire ou leur compétence (traduction, aide, marketing, ...). Et enfin, les utilisateurs utilisent les logiciels, et bénéficient du savoir faire des deux autres catégories. Alors s'il te plaît j'aimerai que l'on évite de dénigrer cette dernière catégorie sous prétexte qu'il faudrai absolument participer à la "vie" de la communauté (quoique utiliser des LL et les montrer à ses amis est déjà en soit une participation.)
[^] # Re: Grrr
Posté par kolter (site web personnel, Mastodon) . Évalué à 2.
ton blog^Wjournal soulève surtout le problème des utilisateurs qui critiquent et VEULENT qu'on corrige les bugs sans contre partie si ce n'est de faire des troll à la "libre vs. proprio" avec des argument que l'on peut largement appliqué au logiciels propriétaires quand ça ne fonctionne pas, et qui l'utilise comme "moyen de pression". C'est assez déplorable comme démarche.
De plus, si une entreprise utilise kmail elle peut payer un dev pour corriger ce bug, quid de la même chose avec un logiciel propriétaire ?
à ton avis ?
"la communauté" , toi aussi tu vis dans le monde des bisounours ?
As tu essayé de contacté (mail / irc) les devs de kmail, et celui qui a programmé cette fonctionalité en particulier pour savoir ce qu'il en est ?
t'es tu réellement bougé pour faire avancer la correction de ce bug ?
M.
[^] # Re: Grrr
Posté par Matthieu Duchemin (site web personnel) . Évalué à 3.
Est ce que j'ai dit : "ils sont nuls ses dev, ils sont pas capable/ne veulent pas implémenter une fonctionnalité dont j'ai envie"? Relis bien mon message, mais je ne crois pas avoir dit quelque chose qui y ressemble. Donc je n'utilise pas ce journal comme moyen de pression. Le LL est un modèle de développement qui a fait ses preuves, mais il dépend du bon vouloir des développeurs (si le dev d'une application ne veut pas corriger un bug, personne ne le fait). Encore une fois je ne porte pas de jugement (après tout, personne ne les obliges à coder, ils le font sur leur temps libre, ils ne perçoivent rien), mais je met avant une des limites du modèle de développement des LL (connaître ses points fort est essentiel, mais connaître ses points faibles et par la même occasion ses limites l'est tout autant). Je vois très bien que tu fais allusions à ces utilisateurs qui veulent absolument qu'une fonctionnalité soit implémenté et qui harcèlent sans cesse les dev pour que ça soit fait, et qui ne comprenne pas que le dev en question ne veut pas que son programme aille dans cette direction, ou qu'il n'a pas le temps. Relis mon journal, et dis moi honnêtement si le ton employé dans mon journal est le même?
Là j'avoue ne pas bien comprendre à quoi tu fais allusion.
Si tu regardes bien il y a 3682 personnes qui ont voté pour ce bug (je fait parti de ceux là. Il faut aussi savoir que le deuxième BUG le plus détesté n'en recueille que ~1600), il y a eu 106 commentaires de fait dont le dernier en date est du 13 avril. Donc pour te répondre, non je n'ai pas contacté les devs de kmail, mais j'ai utilisé le bugzilla qui est mis a disposition pour voter, donc d'une certaine manière j'ai participé. Alors quoi, c'est pas assez, je n'ai pas le niveau requit pour utiliser des LL, je dois donc retourner sous Windows? (ça fait 5 ans que j'ai pas touché à un windows, ça va être dur pour moi).
il y a des gens qui ont proposé des patchs, avec plus ou moins de succès, il y a des personnes qui ont donc essayé de corriger le problème (ce que je n'ai jamais démenti), mais le résultat est là. Au bout de 4 ans le problème existe toujours. Et l'absence d'impératif exigé fait que ce genre de problèmes ne trouvent pas de solutions dans les LL (ça ne veut pas dire que les LL sont nuls, ça ne veut pas dire que le propriétaire c'est mieux). C'est un constat, un simple constat du manque "d'arme" de la communauté face à ce genre de problèmes.
[^] # Re: Grrr
Posté par kolter (site web personnel, Mastodon) . Évalué à 0.
tu fais exprès de faire ta victime ?
comme je l'ai dit plus haut, il y'a d'autre clients mails si celui là ne te convient pas !
je dois donc retourner sous Windows?
ou est le rapport ?
Et l'absence d'impératif exigé fait que ce genre de problèmes ne trouvent pas de solutions dans les LL
J'ai lu le tout le thread concernant ce bug et là c'est pire que tout pour toi car tu te bats pour dire que c'est un simple bug et que personne ne veut le corriger alors que c'est pas le cas, bcp on essayé mais il est expliqué que c'est un problème de design. Il y'a clairement un problème dans les entrées/sorties (pipe, réseau, etc...).
donc le problème finalement c'est que ce que tu dénonces est un peu plus complexe qu'il n'y parait. Pour corriger ce bug, il faudrait retravailler une partie de kmail.
Surtout qu'en plus d'autres pistes sont avancées comme un support de dspam en natif par exemple.
Donc ils y travaillent à leur rythme mais aucune solution satisfaisante n'a été trouvé pour corriger ce bug.
Ce que tu dénonces comme un problème de réactivité n'en ai pas un, c'est un plus subtile que ça!
M.
[^] # Re: Grrr
Posté par Matthieu Duchemin (site web personnel) . Évalué à 1.
c'est un peu en réponse à ça :
et par rapport à d'autres arguments que tu avances, tu laisses l'impression que si on n'est pas content on à qu'à aller voir ailleur, ou coder soit même le truc. Et malheureusement il n'y a pas d'alternative à Kmail sous KDE (ie : qui offre une intégration avec KDE : comme le carnet d'adresse...)
A aucun moment j'ai dit que c'était un bug évident à corriger. Je me souviens au début quelqu'un avait dit que, comme tu le soulignes, c'était un problème de design, et qu'ils n'avaient pas l'intention d'en changer. Au bout de 4ans, ça aurai peut être été bénéfique de changer le design quand même (ce n'est qu'un commentaire). C'est quand même un problème de réactivité. De plus, comme tu le dis, c'est un problème complexe, et peu de gens ont envie de s'attarder dessus (alors que le nombre de votant est important), donc on en reviens bien à un problème de limite du modèle de développement des LL (quand il est fait par une communauté de développeurs bénévoles).
Dans mon cas précis, le support de dspam en natif m'arrangerai bien, mais ça ne règle pas le problème dès que l'on fait appel à une application externe pour filtrer les messages. (mais là on est en train de commenter les avantages et les inconvénients des solutions proposées, ce qui nous fait sortir de la discussion initiale)
[^] # Re: Grrr
Posté par Gniarf . Évalué à -1.
[^] # Re: Grrr
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
Donc inscrit toi a la ml, et lance le débat pour que cela ne soit pas oublier (et ne pas attendre KDE5), ça sera + efficace que de poster un message ici. Car a ma connaissance, il y a ici des développeurs Kopete en pagaille, mais je ne connais pas de dev kmail moulant sur linuxfr.
[^] # Re: Grrr
Posté par yoho (site web personnel) . Évalué à 3.
N'empêche que cela fait un nombre de personne impressionnant sachant qu'il faut avoir un compte bugzilla pour voter, en plus...
[^] # Re: Grrr
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 2.
En fait, c'est 100 pour les bugs d'une même application.
[^] # Re: Grrr
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Il met juste l'accent sur une des faiblesses du libre en général: les gens font en gros ce qu'ils veulent et ce qui les intéresse, les créateurs du logiciel n'ont aucun impératif d'ordre commercial et donc n'ont pas fatalement le soucis de la perfection.
A mes temps perdus, je fais moi même du logiciel libre et je sais que y'a un paquet de soucis mineurs dans mon application qui ne gènent pas son utilisation quotidienne mais que ça me gonfle de corriger, je préfère bosser sur un protocol de transfert de fichier plutôt que de griser un bouton dans un obscure panel de paramétrage. Au boulot, je pourrais pas me permettre de trainer les savattes.
[^] # Re: Grrr
Posté par kolter (site web personnel, Mastodon) . Évalué à 2.
c'est parce que toi tu fais moins d'effort que les projets issus du logiciel libre en font "en general" moins aussi.
M.
[^] # Re: Grrr
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
Chacun à son seuil de perfectionnisme et je ne remets pas en cause celui des gens qui développent du libre, sinon je me tire une balle dans le pied :-).
Quand tu vends un produit et que tes parts de marché dépendent de l'image de ton produit, tu le soignes, tu tiens compte des remarques des clients et pas seulement celles qui te semblent pertinentes. Pas forcément pour que le produit soit meilleur, mais pour vendre et survivre.
Il existe autant de perfectionnistes dans le monde du libre que dans le monde du proprio. Seulement quand tu développes un logiciel libre, tu le fais pour te rendre service et rendre service à d'autres, ou alors pour le challenge ou tout simplement pour s'amuser. On te fous pas un couteau sous la gorge pour corriger un comportement dont un gros client aurait besoin ou alors pour le peaufiner au maximum afin d'optimiser les ventes.
Il existe des défauts dans une application libre non commerciale qui pourraient passer pour rédhibitoires dans une application propriétaire commerciale. Non que ces défauts soient si graves qu'ils diminuent la portée et l'intérêt de l'application en question, mais qu'ils ne permettent pas de le valider dans un appel d'offre ou d'en assurer la pérénité commerciale.
(je fais abusivement la comparaison libre VS. proprio alors qu'en fait il s'agit plutôt de gens payés pour avoir des résultats VS. hobbistes, j'espère que tout le monde aura compris, d'ailleurs, c'est surtout de ça dont il s'agit)
# Pff c'est même pas un ID linuxfr
Posté par Thomas Douillard . Évalué à 2.
# Mouah ah ah !!!
Posté par ondex . Évalué à -5.
Mwarff !!!! Ho ho !!! whouuuu... Elle était bien bonne celle là
# Chez Mandriva...
Posté par yoho (site web personnel) . Évalué à 2.
http://qa.mandriva.com/show_bug.cgi?id=15339
Mais bon, il est déjà fixé avec pinit, alors faudrait peut-être songer à le fermer non ?
# si tu veux vraiment que le bug soit corrigé au plus vite
Posté par Krunch (site web personnel) . Évalué à 1.
- Tu le fais faire par quelqun(s) d'autre. Vu que ce bug a l'air de demander pas mal de travail, un bon moyen de trouver des gens pour travailler sérieusement dessus serait de se cotiser pour offrir une récompense à celui qui produira un patch correct et de faire connaître cette offre aux personnes susceptibles d'être intéressées (ceux qui ont déjà commencé à travailler dessus par exemple).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Encore un peu de patience...
Posté par Seazor . Évalué à 3.
Ca aura de fortes chances de régler ce problème à cette occasion.
Tu peux p'tet voir si ils en parlent sur leur site ou leur ml...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.