D'un autre côté, là il s'agit plus d'erreurs de conception (ton trollesque, expressions mal comprises) que d'erreurs d'implémentation (fautes d'orthographe, de grammaire).
J'ai choisi ce bug là en particulier car il me semblait intéressant. En effet, c'est un bug qui existait depuis très longtemps, sans être révélé. Quand il s'est révélé, plusieurs hypothèses ont été faites, mais personne ne savait trop ce qui causait le probleme. Plusieurs mois après, quelqu'un a pris le temps de vraiment fouiller, et l'a corrigé. Comme c'était un bug particulièrement bien enfoui au fond de gconf, ca lui a probablement pris beaucoup de temps, d'ailleurs quelques personnes l'ont félicité sur leurs blogs, et c'est là que j'en ai entendu parler.
Si une suite de tests unitaires avait été développée en même temps que gconf, ce bug aurait peut-être été révélé par les tests. Après, il faut voir si le temps passé à développer les tests unitaires est inférieur au temps passé à chercher le bug. J'imagine que dans ce cas, ça aurait été rentable. Ce n'est pas toujours le cas.
Disclaimer : le but n'était bien sûr pas de dire que GNOME est pourri et tout buggé. GNOME comporte extrèmement peu de bugs, surtout lorsqu'on regarde la taille du projet ... Et les développeurs GNOME font en général du très bon boulot.
Il suffit de faire un pseudo driver dont tu modfifieras le comportement dans tes tests et via lequel tu verifieras que le reste du systeme se comporte correctement.
Ca s'appelle "stub" ou "bouchon" dans la littérature.
Typiquement, pour le noyau, Linus relit les patchs mais l'inverse est rarement vrai.
Tu veux dire que les patchs ne relisent que rarement Linus ?
En gros, la qualité des logiciels libres serait bonnes mais leur démarche qualité qui n'est pas celle des logiciels propriétaires n'est pas bonne ?
C'est mal passé dans le texte de la dépêche (encore une fois, elle était mal rédigée et tout et tout).
Ce que je dis, c'est que la DEMARCHE qualité des LL est pas mauvaise, mais elle pourrait être meilleure. Après, écrire des tests, ca prend du temps. Ca en prend sur le temps de développement, et ca en fait gagner sur le temps de recherche des bugs plus tard. Parfois, c'est rentable (pt de vue temps) : on économise du temps en faisant des tests. Parfois, ça l'est pas.
Les tests unitaires ne sont pas la réponse à la vie, à l'univers et à tout. C'est un outil parmi d'autres, et parfois il faudrait les utiliser. Actuellement, quasiment personne ne les utilise dans le Libre.
Fichtre ça mérite une première page. T'es une vedette, une star ? :-)
Je n'ai pas demandé qu'on le mette en première page. Si les modérateurs pensent que passer en 2eme page permettrait d'augmenter le niveau des commentaires et d'éviter les attaques ad hominem blessantes, n'hésitez pas :-)
Car tu ne connais pas la démarche qualité. Car il n'y a pas un page de pub pour te la décrire.
Qui es-tu pour attaquer comme ça ? T'es une vedette, une star ? T'as jamais posté de dépêche, jamais posté de journaux, et t'es sur DLFP depuis 11 jours.
On ne parle pas de la même démarche qualité. Je parle de démarche qualité pendant le développement d'un LL, tu parles de démarche qualité pour la sortie d'une distro.
On ne parle pas non plus des mêmes tests. Tu parles des tests par des utilisateurs finaux, je parle des tests unitaires ou d'intégration.
Bref, mon pauvre, t'es complètement à coté de la plaque. Plutot que de poster 20 commentaires pour dire la même chose, tu ferais mieux de te servir de ce que tu as entre les deux oreilles.
En effet, Debian fait énormément d'excellent boulot de ce côté là.
Ma dépêche totalement incomprise (incompréhensible ? ;) essayait de mettre l'accent sur les problèmes de qualité au moment du développement. Debian fait un boulot magnifique après coup. C'est probablement grâce au travail de groupes comme Debian que le manque de "profesionnalisme" dans le développement de la plupart des LL ne se fait pas plus sentir.
On ne sait toujours pas sur quoi concrêtement tu te base.
Sur mon impression générale. Elle est peut-être fausse, je ne sais pas.
j'aimerais savoir depuis combien de temps tu utilises le libre.
1999
Bon, ma dépêche était trollesque, je l'admets. Oublie tout ce qui mentionne LP et fiabilité, concentre toi sur ce qui mentionne les tests, et relis.
Quand je parle de retard, je parlais de retard dans la DEMARCHE qualité, pas dans la QUALITE. Comme me l'a fait fort justement remarquer quelqu'un par mail (coucou Guillaume), le titre de la dépêche était probablement mal choisi : beaucoup de monde a problablement lu "Qualité et Logiciels Libres" au lieu de "Démarche Qualité et Logiciels Libres".
Comme dit dans les commentaires de mon blog ( http://www.lucas-nussbaum.net/blog.php/?2005/02/09/93-depeche-linux(...) ), je n'aurai pas du faire mention des LP dans ma dépêche. En fait, si vous la relisez, vous verrez que je n'insiste pas tant que ça sur le fait que les LPs sont bien testés, contrairement aux LL. Ce n'est même pas dit explicitement. Bref, c'était trop trollesque, mais après tout on est sur DLFP.
- quelles sont les techniques et outils permettant d'automatiser le test des logiciels utilisant des interfaces graphiques ?
Les applis graphiques bien construitent utilisent en général une architecture MVC (Model View Controller). Google explique plutot bien ce que c'est, je ne vais pas tenter une explication foireuse détaillée ici. Juste en 2 lignes : il s'agit de séparer la "logique", le "moteur" de l'application de l'interface.
Une application construite ainsi est facile à tester :
- D'un coté, le Model peut être testé avec des tests unitaires, d'intégration, etc .... comme une appli "classique".
- D'un autre côté, l'interface graphique peut être testée à la main ou avec des outils spécialisés. Mais en général, les bugs ne concernant que l'interface sont assez faciles à trouver, une fois qu'on a bien débuggé le Model.
Cette architecture s'applique également très bien aux applis web, mais est malheureusement peu utilisée : beaucoup d'applis en PHP mélangent allègrement modele et interface (le code de LinuxFR, par exemple, est assez fort dans ce style).
- comment amener les développeurs de Logiciels Libres à tester de manière plus automatisée leurs logiciels, et à ne pas uniquement reposer sur le feedback des utilisateurs ?
Je pense qu'il faut développer plus d'outils de test (le test peut être fun, c'est juste que pour l'instant, on a pas vraiment les bons outils pour ça). Pour DejaGNU par exemple (que je n'ai jamais utilisé), il y a extrèmement peu de documentation orientée introduction. Le lien que je donnais dans la dépêche n'est pas super probant, mais c'est le mieux que j'ai trouvé.
Je ne parle pas d'extrémistes du libre (d'ailleurs je suis plutôt considéré comme un extrémiste du libre) mais d'd'extrémistes du modèle de développement Open Source.
Une proportion non négligeable de développeurs de LL négligent les tests car ils considèrent que c'est aux utilisateurs de les faire. C'est ce comportement que je déplore.
Ensuite, l'excuse du "les LP sont pas fiables, pas de raison de faire des LL fiables", je trouve ça pas génial ;-)
En fait, ma dépêche est une dépêche sur le test, pas sur la fiabilité. Peut-être que beaucoup de personnes n'ont lu que les 4 premières lignes. :-)
Laissons un peu de côté la fiabilité et la comparaison libre/proprio.
Le test par des utilisateurs-testeurs est une démarche qualité incomplète. Ca permet de trouver certains bugs situés assez haut dans le programme, mais pas les bugs bien enfouis. Pourtant (à la louche) aucun logiciel libre n'est testé en profondeur, via tests unitaires par exemple. Ce qui me décoit, plus que la fiabilité générale de GNU/Linux, qui est plutot pas mauvaise, c'est qu'on tombe de temps en temps sur des bugs qui nécessitent un effort considérable CAR les logiciels n'ont pas été correctement testés.
A mon avis, pour passer à l'étape suivante, les logiciels libres ont besoin d'etre testés correctement, et ne peuvent plus se contenter de l'approche actuelle ("c'est mes utilisateurs qui font les tests, moi je code").
Beaucoup d'éditeurs de LP l'ont compris, donc la communauté du Libre prend du retard qui ne sera pas évident à rattraper.
Pfff, et si on arrêtait un peu de troller ? Je trolle jamais avant 10h du matin moi !
Sourceforge, c'est la poubelle du libre. T'as 90% de projets morts... C'est pas vraiment un bon endroit pour mesurer la popularité d'un langage.
Franchement, cite moi 10 projets importants (déf d'important : dont une partie non négligeable de la communauté a entendu parler) écrits en Java, et ne concernant pas le développement web (donc pas de Jonas, Jakarta, etc.)
L'utilisation de Java est anecdotique dans la communauté du LL, et je ne dis pas que ça en fait un mauvais langage, juste qu'il n'est pas très utilisé :-) Maintenant, j'ai oublié de citer Java, c'est aussi parce qu'il est difficile de développer des applis de haut niveau pour GNU/Linux en Java actuellement, à cause du manque de bindings pour pas mal d'autres librairies. (Oui, il y a des contre-exemples)
Bon, c'est moi qui ai posté la news. Je vais répondre en bloc à pas mal de remarques vues dans les commentaires. Mais d'abord, le but de la news est de faire prendre conscience que tout n'est pas parfait au royaume du libre. Et les commentaires ne m'ont pas fait changer d'avis.
Exemples donnés : Mozilla, GCC
Oui, à mon avis, Mozilla est peut-être un peu moins buggé que IE. Oui, il y a des logiciels libres qui sont très fiables (j'en cite d'ailleurs dans la news). Souvent, ils sont testés correctement (cf Gcc). Mais la très grande majorité des LL ne sont pas d'une fiabilité irréprochable (loin de là)
Java
Pour Java, c'est vrai que j'ai oublié de le citer (mea culpa). Mais l'utilisation de Java dans la communauté (pour produire des logiciels libres) reste assez anecdotique.
Outils de test pour C/C++
Après, j'ai eu droit à une liste exhaustive de moyens de tester du C, du C++. Oui, bien sûr, ca existe. Mais le problème, c'est que leur existence ne suffit pas à rendre tous les pgmes C/C++ moins buggés d'un seul coup. Il faut les utiliser. Et y a pas grand monde qui le fait.
Le bug de gconfd
L'exemple du bug de gconfd était intéressant car il s'agissait d'un bug enfoui très loin dans le code. C'est le genre de bugs très difficile à faire remonter par un utilisateur, car il peut être rencontré de manières très différentes et pas forcément fréquentes. De plus, c'est typiquement le genre de bugs qui est facile à détecter avec des tests.
"Certains logiciels propriétaires sont buggés eux aussi"
Ca, c'est le raisonnement le pire. "On fait du code pourri, mais c'est pas grave, les autres aussi !" Dans la dépeche, je disais "Logiciels propriétaires populaires", pas "Tous les softs proprios". Tout ce que je veux dire, c'est que les softs propriétaires ont fait (pour beaucoup) de gros efforts côté qualité ces derniers temps, et que l'argument des logiciels libres plus fiables ne tient plus vraiment. La qualité des LL et des LP devient (à la louche) égale. Et pour que les LL reprennent la tête, il faudrait que beaucoup de développeurs acceptent de voir leur code d'une manière un peu moins biaisée, et se rendent compte qu'il contient des bugs et que le tester peut améliorer les choses.
Oula, tu passes un peu vite à ta conclusion ! Le test n'est pas une discipline si simple ! Toute formation de niveau bac+4/5 qui se respecte y consacre au moins un cours d'une 10aine d'heures pour une introduction ...
Pour la vérification de la couverture, on ne regarde bien sûr pas que les lignes couvertures par les tests. On peut aussi chercher une couverture des chemins (où on regarde quels chemins d'execution ont été couverts dans le programme), ou une couverture des expressions (on peut vérifier que les 2 membres d'une expr booléenne ont été évalués au moins une fois à vrai et à faux, par exemple). Bref, il y a des tonnes de critères. Tu dois pouvoir trouver un cours sur le test sur le net.
Et puis, il ne faut pas oublier que la couverture n'est pas une fin en soi : elle doit être utilisée uniquement comme une mesure de la qualité du jeu de test.
L'utilisation à en faire est :
- écrire un jeu de test
- regarder sa couverture, analyser quels sont les points mal testés
- compléter le jeu de test en insistant sur les points mal testés, sans chercher de manière explicite à couvrir les lignes non couvertes jusqu'à maintenant
- regarder la couverture du jeu de test après modif
- ...
Il ne faut surtout pas chercher à obtenir 100% de couverture en regardant la couverture après chaque écriture de test !
Pas sûr, je pense que les ensembles sont inclus les uns dans les autres (parmi les 8 qui ont posté au moins 50 news, il y a les 3 qui en ont posté au moins 100).
D'après les stats, on a l'impression que c'est les "petits posteurs" qui postent le plus de news, même s'il y a une grosse majorité silencieuse qui ne propose jamais de news. Ca serait intéressant d'avoir les stats sur les 12 derniers mois.
Ca pourrait etre une fonctionnalité dans LinuxFr, genre quand on poste un journal, pouvoir selectionner un journal précédemment posté. Faut voir si ce serait utile aussi.
Je ne pense pas que LinuxFR s'y prête. Le fait d'avoir tellement de contributeurs différents noie forcément le ton de chacun dans la masse. Quand je lis un journal DLFP, je ne regarde que rarement qui l'a écrit, et je pense que c'est un peu pareil pour tout le monde...
Oui, mais le problème est que des personnes votent sur des sujets qu'ils ne maitrisent pas, en se disant "lui il insiste, il a probablement raison."
Il suffit de regarder les journaux sur un sujet difficile comme les licences. Beaucoup de gens pensent maitriser le sujet, et cela se voit dans les commentaires : tout le monde est certain de son avis, et il y a au moins 50% de conneries dans les commentaires. Sur ce genre de sujets, LinuxFR n'arrive pas à absorber les nouveaux venus, qui croyent ensuite que leur interprétation est juste car ils l'ont vu sur DLFP.
Il serait intéressant de connaitre la répartition des posteurs. Je me demande si ce n'est pas une autre illustration de la loi de Zipf[0], avec 10% des posteurs qui postent 90% des news.
En fait, je pense que LinuxFR est un site d'une autre époque. Actuellement, il est beaucoup plus facile de publier ses écrits, et d'être lu, qu'il y a quelques années. Peut-être faudrait-il faire évoluer LinuxFR vers un site avec une équipe de rédacteurs, plutot que d'attendre des lecteurs qu'ils postent de temps en temps des news dont l'uniformisation prend un max de temps.
En fait, si je contribue peu à LinuxFR, c'est que je vois énormément d'avantages à poster sur mon blog à la place :
- Je peux décider du ton de mon blog, sans avoir à coller à celui de LinuxFR.
- J'ai moins de lecteurs, avec des commentaires bien plus intéressants que ceux de DLFP.
- Il y a une constance dans le temps : je peux faire référence à un billet précédent. Sur DLFP, on ne peut pas dire "Dans la dépêche X, je disais ça, je vais développer un peu".
- Je ne suis pas modéré, la publication est immédiate
gna gna gna
Le dessin dont tu parles ( http://www.lucas-nussbaum.net/img/lechat.jpg(...) ) m'a été envoyé dans une "carte postale électronique" il y a bien longtemps. J'imagine donc que la diffusion sans modification est tolérée, ce que je fais. Bien sûr, je n'en suis pas certain. Mais Casterman n'indiquait pas dans la carte postale qu'on ne devait pas continuer à diffuser le dessin (ce que j'aurais fait en forwardant le mail par exemple).
Dans ton cas, Adobe demande clairement de ne pas diffuser Acrobat Reader 7, et tu le fais quand même, en utilisant les services d'un hébergeur fortement engagé pour le libre. En faisant cela, tu prends des risques, et tu en fais prendre à ton hébergeur, à qui tu n'as rien demandé.
Tu as décidé de déplacer le fichier sur le serveur web du GPL. Pourquoi pas. Mais au lieu de critiquer ma question, tu ferais mieux d'y répondre : le propriétaire du serveur est-il au courant que tu t'en sers pour diffuser des fichiers que tu n'as pas le droit de diffuser ?
[^] # Re: Je ne suis pas d'accord
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
Bon, ok, si, quand même ...
-->[]
[^] # Re: Intro aux tests logiciels
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
[^] # Re: Pourquoi tant de haine
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 3.
Donc les tests unitaires n'auraient rien décelé.
Lucas, qui a oublié ses tests d'adéquation
[^] # Re: Ah oui mais...
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 3.
Si une suite de tests unitaires avait été développée en même temps que gconf, ce bug aurait peut-être été révélé par les tests. Après, il faut voir si le temps passé à développer les tests unitaires est inférieur au temps passé à chercher le bug. J'imagine que dans ce cas, ça aurait été rentable. Ce n'est pas toujours le cas.
Disclaimer : le but n'était bien sûr pas de dire que GNOME est pourri et tout buggé. GNOME comporte extrèmement peu de bugs, surtout lorsqu'on regarde la taille du projet ... Et les développeurs GNOME font en général du très bon boulot.
[^] # Re: La démarche qualité existe - elle est seulement différente
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 3.
Ca s'appelle "stub" ou "bouchon" dans la littérature.
Typiquement, pour le noyau, Linus relit les patchs mais l'inverse est rarement vrai.
Tu veux dire que les patchs ne relisent que rarement Linus ?
=>[]
[^] # Re: Droit de réponse
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
Ah, je savais plus. Du coup j'ai cherché sur Google, qui m'a dit : "The Answer to Life, the Universe, and Everything"
Merci
[^] # Re: Droit de réponse
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
C'est mal passé dans le texte de la dépêche (encore une fois, elle était mal rédigée et tout et tout).
Ce que je dis, c'est que la DEMARCHE qualité des LL est pas mauvaise, mais elle pourrait être meilleure. Après, écrire des tests, ca prend du temps. Ca en prend sur le temps de développement, et ca en fait gagner sur le temps de recherche des bugs plus tard. Parfois, c'est rentable (pt de vue temps) : on économise du temps en faisant des tests. Parfois, ça l'est pas.
Les tests unitaires ne sont pas la réponse à la vie, à l'univers et à tout. C'est un outil parmi d'autres, et parfois il faudrait les utiliser. Actuellement, quasiment personne ne les utilise dans le Libre.
[^] # Re: ???
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
Apparemment Bull bosse sur ce genre de projets. Liens :
http://nfsv4.bullopensource.org/tools/testing_tools.html(...)
http://ltp.sourceforge.net/(...)
Mais ca se limite à un projet phare (Linux), et ca n'est pas vraiment représentatif de l'ensemble des LL.
[^] # Re: Droit de réponse
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 7.
Je n'ai pas demandé qu'on le mette en première page. Si les modérateurs pensent que passer en 2eme page permettrait d'augmenter le niveau des commentaires et d'éviter les attaques ad hominem blessantes, n'hésitez pas :-)
Car tu ne connais pas la démarche qualité. Car il n'y a pas un page de pub pour te la décrire.
Qui es-tu pour attaquer comme ça ? T'es une vedette, une star ? T'as jamais posté de dépêche, jamais posté de journaux, et t'es sur DLFP depuis 11 jours.
On ne parle pas de la même démarche qualité. Je parle de démarche qualité pendant le développement d'un LL, tu parles de démarche qualité pour la sortie d'une distro.
On ne parle pas non plus des mêmes tests. Tu parles des tests par des utilisateurs finaux, je parle des tests unitaires ou d'intégration.
Bref, mon pauvre, t'es complètement à coté de la plaque. Plutot que de poster 20 commentaires pour dire la même chose, tu ferais mieux de te servir de ce que tu as entre les deux oreilles.
[^] # Re: Et Debian ?
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 4.
Ma dépêche totalement incomprise (incompréhensible ? ;) essayait de mettre l'accent sur les problèmes de qualité au moment du développement. Debian fait un boulot magnifique après coup. C'est probablement grâce au travail de groupes comme Debian que le manque de "profesionnalisme" dans le développement de la plupart des LL ne se fait pas plus sentir.
[^] # Re: Droit de réponse
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
Sur mon impression générale. Elle est peut-être fausse, je ne sais pas.
j'aimerais savoir depuis combien de temps tu utilises le libre.
1999
Bon, ma dépêche était trollesque, je l'admets. Oublie tout ce qui mentionne LP et fiabilité, concentre toi sur ce qui mentionne les tests, et relis.
Quand je parle de retard, je parlais de retard dans la DEMARCHE qualité, pas dans la QUALITE. Comme me l'a fait fort justement remarquer quelqu'un par mail (coucou Guillaume), le titre de la dépêche était probablement mal choisi : beaucoup de monde a problablement lu "Qualité et Logiciels Libres" au lieu de "Démarche Qualité et Logiciels Libres".
[^] # Re: Motivation initiale
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 3.
- quelles sont les techniques et outils permettant d'automatiser le test des logiciels utilisant des interfaces graphiques ?
Les applis graphiques bien construitent utilisent en général une architecture MVC (Model View Controller). Google explique plutot bien ce que c'est, je ne vais pas tenter une explication foireuse détaillée ici. Juste en 2 lignes : il s'agit de séparer la "logique", le "moteur" de l'application de l'interface.
Une application construite ainsi est facile à tester :
- D'un coté, le Model peut être testé avec des tests unitaires, d'intégration, etc .... comme une appli "classique".
- D'un autre côté, l'interface graphique peut être testée à la main ou avec des outils spécialisés. Mais en général, les bugs ne concernant que l'interface sont assez faciles à trouver, une fois qu'on a bien débuggé le Model.
Cette architecture s'applique également très bien aux applis web, mais est malheureusement peu utilisée : beaucoup d'applis en PHP mélangent allègrement modele et interface (le code de LinuxFR, par exemple, est assez fort dans ce style).
- comment amener les développeurs de Logiciels Libres à tester de manière plus automatisée leurs logiciels, et à ne pas uniquement reposer sur le feedback des utilisateurs ?
Je pense qu'il faut développer plus d'outils de test (le test peut être fun, c'est juste que pour l'instant, on a pas vraiment les bons outils pour ça). Pour DejaGNU par exemple (que je n'ai jamais utilisé), il y a extrèmement peu de documentation orientée introduction. Le lien que je donnais dans la dépêche n'est pas super probant, mais c'est le mieux que j'ai trouvé.
[^] # Re: Libre...
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
Une proportion non négligeable de développeurs de LL négligent les tests car ils considèrent que c'est aux utilisateurs de les faire. C'est ce comportement que je déplore.
Ensuite, l'excuse du "les LP sont pas fiables, pas de raison de faire des LL fiables", je trouve ça pas génial ;-)
[^] # Re: Droit de réponse
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 3.
Laissons un peu de côté la fiabilité et la comparaison libre/proprio.
Le test par des utilisateurs-testeurs est une démarche qualité incomplète. Ca permet de trouver certains bugs situés assez haut dans le programme, mais pas les bugs bien enfouis. Pourtant (à la louche) aucun logiciel libre n'est testé en profondeur, via tests unitaires par exemple. Ce qui me décoit, plus que la fiabilité générale de GNU/Linux, qui est plutot pas mauvaise, c'est qu'on tombe de temps en temps sur des bugs qui nécessitent un effort considérable CAR les logiciels n'ont pas été correctement testés.
A mon avis, pour passer à l'étape suivante, les logiciels libres ont besoin d'etre testés correctement, et ne peuvent plus se contenter de l'approche actuelle ("c'est mes utilisateurs qui font les tests, moi je code").
Beaucoup d'éditeurs de LP l'ont compris, donc la communauté du Libre prend du retard qui ne sera pas évident à rattraper.
[^] # Re: Droit de réponse
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 2.
Sourceforge, c'est la poubelle du libre. T'as 90% de projets morts... C'est pas vraiment un bon endroit pour mesurer la popularité d'un langage.
Franchement, cite moi 10 projets importants (déf d'important : dont une partie non négligeable de la communauté a entendu parler) écrits en Java, et ne concernant pas le développement web (donc pas de Jonas, Jakarta, etc.)
L'utilisation de Java est anecdotique dans la communauté du LL, et je ne dis pas que ça en fait un mauvais langage, juste qu'il n'est pas très utilisé :-) Maintenant, j'ai oublié de citer Java, c'est aussi parce qu'il est difficile de développer des applis de haut niveau pour GNU/Linux en Java actuellement, à cause du manque de bindings pour pas mal d'autres librairies. (Oui, il y a des contre-exemples)
# Droit de réponse
Posté par Lucas . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 9.
Exemples donnés : Mozilla, GCC
Oui, à mon avis, Mozilla est peut-être un peu moins buggé que IE. Oui, il y a des logiciels libres qui sont très fiables (j'en cite d'ailleurs dans la news). Souvent, ils sont testés correctement (cf Gcc). Mais la très grande majorité des LL ne sont pas d'une fiabilité irréprochable (loin de là)
Java
Pour Java, c'est vrai que j'ai oublié de le citer (mea culpa). Mais l'utilisation de Java dans la communauté (pour produire des logiciels libres) reste assez anecdotique.
Outils de test pour C/C++
Après, j'ai eu droit à une liste exhaustive de moyens de tester du C, du C++. Oui, bien sûr, ca existe. Mais le problème, c'est que leur existence ne suffit pas à rendre tous les pgmes C/C++ moins buggés d'un seul coup. Il faut les utiliser. Et y a pas grand monde qui le fait.
Le bug de gconfd
L'exemple du bug de gconfd était intéressant car il s'agissait d'un bug enfoui très loin dans le code. C'est le genre de bugs très difficile à faire remonter par un utilisateur, car il peut être rencontré de manières très différentes et pas forcément fréquentes. De plus, c'est typiquement le genre de bugs qui est facile à détecter avec des tests.
"Certains logiciels propriétaires sont buggés eux aussi"
Ca, c'est le raisonnement le pire. "On fait du code pourri, mais c'est pas grave, les autres aussi !" Dans la dépeche, je disais "Logiciels propriétaires populaires", pas "Tous les softs proprios". Tout ce que je veux dire, c'est que les softs propriétaires ont fait (pour beaucoup) de gros efforts côté qualité ces derniers temps, et que l'argument des logiciels libres plus fiables ne tient plus vraiment. La qualité des LL et des LP devient (à la louche) égale. Et pour que les LL reprennent la tête, il faudrait que beaucoup de développeurs acceptent de voir leur code d'une manière un peu moins biaisée, et se rendent compte qu'il contient des bugs et que le tester peut améliorer les choses.
# pas une preuve
Posté par Lucas . En réponse au journal couverture de code. Évalué à 4.
Et puis un test n'est pas une preuve que le programme est correct, juste un moyen de trouver des erreurs...
# Pas si simple...
Posté par Lucas . En réponse au journal couverture de code. Évalué à 6.
Pour la vérification de la couverture, on ne regarde bien sûr pas que les lignes couvertures par les tests. On peut aussi chercher une couverture des chemins (où on regarde quels chemins d'execution ont été couverts dans le programme), ou une couverture des expressions (on peut vérifier que les 2 membres d'une expr booléenne ont été évalués au moins une fois à vrai et à faux, par exemple). Bref, il y a des tonnes de critères. Tu dois pouvoir trouver un cours sur le test sur le net.
Et puis, il ne faut pas oublier que la couverture n'est pas une fin en soi : elle doit être utilisée uniquement comme une mesure de la qualité du jeu de test.
L'utilisation à en faire est :
- écrire un jeu de test
- regarder sa couverture, analyser quels sont les points mal testés
- compléter le jeu de test en insistant sur les points mal testés, sans chercher de manière explicite à couvrir les lignes non couvertes jusqu'à maintenant
- regarder la couverture du jeu de test après modif
- ...
Il ne faut surtout pas chercher à obtenir 100% de couverture en regardant la couverture après chaque écriture de test !
Bon, c'est pas tout ça, mais j'ai cours.
# RSS ...
Posté par Lucas . En réponse au journal Un nouveau blogeur. Évalué à 1.
[^] # Re: Je me plains
Posté par Lucas . En réponse au journal LinuxFR sur la pente descendante ?. Évalué à 3.
D'après les stats, on a l'impression que c'est les "petits posteurs" qui postent le plus de news, même s'il y a une grosse majorité silencieuse qui ne propose jamais de news. Ca serait intéressant d'avoir les stats sur les 12 derniers mois.
[^] # Re: Je me plains
Posté par Lucas . En réponse au journal LinuxFR sur la pente descendante ?. Évalué à 2.
Je ne pense pas que LinuxFR s'y prête. Le fait d'avoir tellement de contributeurs différents noie forcément le ton de chacun dans la masse. Quand je lis un journal DLFP, je ne regarde que rarement qui l'a écrit, et je pense que c'est un peu pareil pour tout le monde...
[^] # Re: Une parfaite illustration de tes propos ?
Posté par Lucas . En réponse au journal LinuxFR sur la pente descendante ?. Évalué à 6.
Il suffit de regarder les journaux sur un sujet difficile comme les licences. Beaucoup de gens pensent maitriser le sujet, et cela se voit dans les commentaires : tout le monde est certain de son avis, et il y a au moins 50% de conneries dans les commentaires. Sur ce genre de sujets, LinuxFR n'arrive pas à absorber les nouveaux venus, qui croyent ensuite que leur interprétation est juste car ils l'ont vu sur DLFP.
[^] # Re: Je me plains
Posté par Lucas . En réponse au journal LinuxFR sur la pente descendante ?. Évalué à 7.
En fait, je pense que LinuxFR est un site d'une autre époque. Actuellement, il est beaucoup plus facile de publier ses écrits, et d'être lu, qu'il y a quelques années. Peut-être faudrait-il faire évoluer LinuxFR vers un site avec une équipe de rédacteurs, plutot que d'attendre des lecteurs qu'ils postent de temps en temps des news dont l'uniformisation prend un max de temps.
En fait, si je contribue peu à LinuxFR, c'est que je vois énormément d'avantages à poster sur mon blog à la place :
- Je peux décider du ton de mon blog, sans avoir à coller à celui de LinuxFR.
- J'ai moins de lecteurs, avec des commentaires bien plus intéressants que ceux de DLFP.
- Il y a une constance dans le temps : je peux faire référence à un billet précédent. Sur DLFP, on ne peut pas dire "Dans la dépêche X, je disais ça, je vais développer un peu".
- Je ne suis pas modéré, la publication est immédiate
sinon, Amaury, merci de ton soutien ;)
[0] http://en.wikipedia.org/wiki/Zipf's_law(...) (pas de version francaise)
[^] # Re: Déplacé
Posté par Lucas . En réponse au journal Acrobat reader 7 béta. Évalué à 3.
Le dessin dont tu parles ( http://www.lucas-nussbaum.net/img/lechat.jpg(...) ) m'a été envoyé dans une "carte postale électronique" il y a bien longtemps. J'imagine donc que la diffusion sans modification est tolérée, ce que je fais. Bien sûr, je n'en suis pas certain. Mais Casterman n'indiquait pas dans la carte postale qu'on ne devait pas continuer à diffuser le dessin (ce que j'aurais fait en forwardant le mail par exemple).
Dans ton cas, Adobe demande clairement de ne pas diffuser Acrobat Reader 7, et tu le fais quand même, en utilisant les services d'un hébergeur fortement engagé pour le libre. En faisant cela, tu prends des risques, et tu en fais prendre à ton hébergeur, à qui tu n'as rien demandé.
Tu as décidé de déplacer le fichier sur le serveur web du GPL. Pourquoi pas. Mais au lieu de critiquer ma question, tu ferais mieux d'y répondre : le propriétaire du serveur est-il au courant que tu t'en sers pour diffuser des fichiers que tu n'as pas le droit de diffuser ?
# Déplacé
Posté par Lucas . En réponse au journal Acrobat reader 7 béta. Évalué à 1.