En fait il faudrait définir 2 types de bugs:
- ceux liés aux tests de la nouvelle version (=en RECETTE)
- ceux remontés par les utilisateurs sur la version stable (= en PROD)
Pour moi, les deux catégories sont valables et doivent être étudiées :
La première car cela permet de se donner une indication du niveau de qualité des développements de la nouvelle version (ou du niveau d'exigence des testeurs).
On peut ainsi sortir des stats par appli / par fonctionnalité et regarder quelles sont les nouveautés qui ont généré le plus de bugs.
Exemple: le projet Ktoto, qui présente 100 fonctionnalités par 7 développeurs a provoqué 12 bugs de recette.
Le projet Ktiti lui, présente 50 fonctionnalités avec 8 développeurs mais a engendré 214 bugs.
=> qu'est ce qui fait que le projet Ktiti a été relativement mal codé par rapport au projet Ktoto, que peut on faire pour améliorer le truc ?
l'équipe de dev est elle consciente du truc, travaille t elle rigoureusement avec peu de régressions, utilise t elle les bons outils (que le projet Ktoto pourrait lui conseiller) ?
Ok ça peut sembler un peu extrême mais ça peut servir.
La 2e catégorie de bugs permet aussi de se donner une idée du niveau de qualité final de la version stable.
On peut en sortir des stats sur les bugs / appli ou / fonctionnalité et d'en tirer des conclusions : "Tiens cette partie là n'a pas été assez recettée, vu le nb de bugs en prod. Pourquoi ? Vu la criticité des bugs, est ce que cela vaut le coup qu'on teste ça en priorité ou pas dans la prochaine version ?"
Bien sur que si, puisqu'il était aussi premier en % des suffrages exprimés au 1er tour.
On peut donc affirmer que la majorité des français ont voté pour lui, en majorité relative au 1er tour, et absolue au 2e.
Que ceux qui ne veulent pas voter ne viennent pas se plaindre que ceux qui votent le fassent ! Ils n'ont pas d'autre choix que d'accepter une décision prise sans eux, car ils n'y ont pas participé.
Les pilotes ATI et le bordel des APIs sur la gestion du son sous Linux sont du passé pour toi ?
D'autre part il le dit lui-même, il n'a pas envie de passer trop de temps à tenir son système à jour chez lui.
Ceci dit il provoque un peu la réaction du linuxien, c'est rigolo ça marche :)
Arrête de détourner le débat vers les "petits chefs", pour le coup l'abruti n'en faisait pas partie.
On sait très bien que c'est le vélo qui rend les gens aggressifs, on en a la preuve tous les jours.
Vite un projet de loi sur la déliquance cyclopédique !
Marrant, quand je vais sur l'article, et que je recherche cette phrase, firefox ne la trouve pas.
Bizarre.
A moins que tu parle des commentaires, ce qui dans ce cas là n'as RIEN a voir avec l'article.
Donc je confirme, tu invente bien pour pouvoir etre agressif
C'est dans un commentaire de l'auteur sous son propre article.
Je ne vois donc pas en quoi ça n'a rien à voir avec l'article. Au passage, Julien a déjà indiqué que c'était dans les commentaires, pas dans l'article; sur ce coup c'est toi qui est agressif.
Finalement on a trouvé l'origine du bug de la tribune qui faisait que domi< ratait le preums et postait à 00:00:20 ?
Me souviens plus de l'explication de pterjan.
Il doit rester des trucs pas nets dans les coins, tout de même....
Si l'on assiste aujourd'hui à une ouverture de Java, c'est uniquement à cause de l'arrivée de .net. Sans cela, on en serrait encore à télécharger le fichier binaire jre sur le site de Sun, car non inclus dans la distribution.
Pas d'accord sur ce point.
La plateforme Java n'a pas attendu l'arrivée de .Net pour attirer de gros projets et logiciels libres (Apache/Tomcat, JBoss, Eclipse...).
Java étant naturellement plus présent sur le monde des serveurs Unix que côté serveurs Microsoft, le passage vers Linux par "association d'idée" est naturel.
Cela me semble être une explication plus plausible que la menace .Net, qui n'existait pas il y a 5 ans.
Quant à l'interface graphique, son aspect dépend uniquement du look & feel que tu définis, et en Java tu peux prendre celui de la plateforme de l'OS sur lequel la JVM tourne. Donc...
Désolé, mais créer des classes avec le mot clef function, et des méthodes avec maclasse.prototype{ methode: pouet() }, je trouve ça illisible et fouilli.
Si on veut faire de l'objet, on instaure des règles pour définir proprement attributs, méthodes et héritage.
Je n'ai pas l'impression que ce soit le cas en Javascript.
On s'en sort avec des astuces et de la bidouille, mais le langage devrait être nettement plus propre.
Maintenant si ne m'abuse, il n'existe pratiquement rien pour faciliter la vie du développeur et assurer que le code soit un minimum propre.
Là où Java, C# ont des outils, frameworks et règles de code assez bien fournis (je ne parle pas de C, C++ pas vraiment adaptés au web).
Désolé, mais Javascript me semble trop fouilli pour être utilisable correctement, et je maintiens mon parallèle avec PHP d'il y a quelques années.
Mais je veux bien admettre ne pas être au courant de toutes les dernières nouveautés et outils JS :)
C'est vrai que le faut que le javascript se comporte tellement différemment entre différents navigateurs n'aide vraiment pas.
Au final on se retrouve avec un langage:
- avec une syntaxe trop permissive
- sans éditeur digne de ce nom (sauf si vous connaissez un éditeur ou plugin éclipse qui vous sort les warnings/erreurs d'exécution JS)
- difficile à débugger (super le débug à coup de alert)
- dont le comportement dépend du navigateur final
- dont le comportement dépend du niveau de sécurité du poste
La situation est même pire que celle de PHP :p
Pourquoi le W3C n'a pas pris les devants en proposant d'intégrer dans HTML quelques fonctionnalités "standard" supplémentaires ?
Actuellement on a déjà des onclick(), onmouseover(), etc...
Pourquoi n'aurait-on pas en natif HTML :
- des fonctions génériques du genre check() sur un champ d'un formulaire, pour vérifier par exemple que ce champ contient tel type de données (cf regexp).
- le même genre de fonctions mais qui t'empêcherait de saisir un caractère d'un type non autorisé dans un champ. Je sais qu'on peut le faire actuellement, mais il faut gérer en plus de la saisie au clavier, le copier/coller...
- une gestion des erreurs sur un formulaire entier, qui te sortirait par exemple la liste des champs ne validant pas la fonction check()
...
Les formulaires JS sont plus que courants actuellement, et ce genre de besoins existe sur tous les sites.
C'est dommage de se faire chier à devoir prendre un framework JS pour ça.
Et alors ?
Ce n'est pas gênant, au contraire, cela permet de changer d'organisation si un imprévu se produit.
Cela n'empêche pas du tout de s'organiser à l'avance. Si vous appréciez un minimum d'organisation et qu'une sortie est prévue au dernier moment, personne ne vous force à y aller.
Comment veux tu empêcher Ned de troller sur Fortran ?
On devrait mettre un disclaimer sur linuxfr indiquant: "attention si vous poster quelque chose concernant Fortran, attendez vous à être sévérement trollés par Ned".
[^] # Re: Plus de 10 000... Correction de bugs ?
Posté par Pierre Tramonson . En réponse à la dépêche KDE 4.3 est sorti. Évalué à 2.
- ceux liés aux tests de la nouvelle version (=en RECETTE)
- ceux remontés par les utilisateurs sur la version stable (= en PROD)
Pour moi, les deux catégories sont valables et doivent être étudiées :
La première car cela permet de se donner une indication du niveau de qualité des développements de la nouvelle version (ou du niveau d'exigence des testeurs).
On peut ainsi sortir des stats par appli / par fonctionnalité et regarder quelles sont les nouveautés qui ont généré le plus de bugs.
Exemple: le projet Ktoto, qui présente 100 fonctionnalités par 7 développeurs a provoqué 12 bugs de recette.
Le projet Ktiti lui, présente 50 fonctionnalités avec 8 développeurs mais a engendré 214 bugs.
=> qu'est ce qui fait que le projet Ktiti a été relativement mal codé par rapport au projet Ktoto, que peut on faire pour améliorer le truc ?
l'équipe de dev est elle consciente du truc, travaille t elle rigoureusement avec peu de régressions, utilise t elle les bons outils (que le projet Ktoto pourrait lui conseiller) ?
Ok ça peut sembler un peu extrême mais ça peut servir.
La 2e catégorie de bugs permet aussi de se donner une idée du niveau de qualité final de la version stable.
On peut en sortir des stats sur les bugs / appli ou / fonctionnalité et d'en tirer des conclusions : "Tiens cette partie là n'a pas été assez recettée, vu le nb de bugs en prod. Pourquoi ? Vu la criticité des bugs, est ce que cela vaut le coup qu'on teste ça en priorité ou pas dans la prochaine version ?"
Bref, je ne suis pas d'accord avec toi :)
[^] # Re: Ce n'est pas Hadopi
Posté par Pierre Tramonson . En réponse au journal Les allemands aussi on leur hadopi. Évalué à 2.
On peut donc affirmer que la majorité des français ont voté pour lui, en majorité relative au 1er tour, et absolue au 2e.
Que ceux qui ne veulent pas voter ne viennent pas se plaindre que ceux qui votent le fassent ! Ils n'ont pas d'autre choix que d'accepter une décision prise sans eux, car ils n'y ont pas participé.
[^] # Re: Anti-Windowsiens primaire
Posté par Pierre Tramonson . En réponse à la dépêche Une interview de Brad Spengler. Évalué à 0.
D'autre part il le dit lui-même, il n'a pas envie de passer trop de temps à tenir son système à jour chez lui.
Ceci dit il provoque un peu la réaction du linuxien, c'est rigolo ça marche :)
[^] # Re: Généralité
Posté par Pierre Tramonson . En réponse au journal Vélib: agressivité du personnel de maintenance. Évalué à 9.
On sait très bien que c'est le vélo qui rend les gens aggressifs, on en a la preuve tous les jours.
Vite un projet de loi sur la déliquance cyclopédique !
[^] # Re: Très puissant et utile
Posté par Pierre Tramonson . En réponse à la dépêche Audacity 1.3.8 dans les bacs. Évalué à 5.
Je trouve que les voix des chanteuses ressortent nettement. Je ne regrette pas mon investissement.
Je vais peut-être y rajouter un ampli à lampes, pour avoir le top du top.
# Décharger avaler
Posté par Pierre Tramonson . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 1.
En tout cas on peut leur dire "good job", pour rester dans le ton.
# Aspect graphique
Posté par Pierre Tramonson . En réponse à la dépêche Nouvelle version des sites Internet des mairies d’arrondissement de Paris sous Lutèce 2.3. Évalué à 3.
Je trouve ça assez laid, surtout le bas de page qui est trop présent, mais bon les gouts et les couleurs...
[^] # Re: Pinaise
Posté par Pierre Tramonson . En réponse à la dépêche Retour sur le quizz des onze ans du site LinuxFr.org. Évalué à 4.
[^] # Re: Quelques details supplementaires donnes par le charlot
Posté par Pierre Tramonson . En réponse au journal vélib...suite. Évalué à 5.
Marrant, quand je vais sur l'article, et que je recherche cette phrase, firefox ne la trouve pas.
Bizarre.
A moins que tu parle des commentaires, ce qui dans ce cas là n'as RIEN a voir avec l'article.
Donc je confirme, tu invente bien pour pouvoir etre agressif
C'est dans un commentaire de l'auteur sous son propre article.
Je ne vois donc pas en quoi ça n'a rien à voir avec l'article. Au passage, Julien a déjà indiqué que c'était dans les commentaires, pas dans l'article; sur ce coup c'est toi qui est agressif.
[^] # Re: tribune
Posté par Pierre Tramonson . En réponse à la dépêche Retour d'expérience sécurité sur 11 ans de LinuxFr.org. Évalué à 6.
Me souviens plus de l'explication de pterjan.
Il doit rester des trucs pas nets dans les coins, tout de même....
[^] # Re: LinuxFR
Posté par Pierre Tramonson . En réponse au journal Dans lequel on aborde la question du Tibet. Évalué à 2.
[^] # Re: La faute à qui ?
Posté par Pierre Tramonson . En réponse au journal Mono: C’est un grave danger et seuls les imbéciles l’ignoreront, jusqu’au jour où il sera trop tard.. Évalué à 3.
Pas d'accord sur ce point.
La plateforme Java n'a pas attendu l'arrivée de .Net pour attirer de gros projets et logiciels libres (Apache/Tomcat, JBoss, Eclipse...).
Java étant naturellement plus présent sur le monde des serveurs Unix que côté serveurs Microsoft, le passage vers Linux par "association d'idée" est naturel.
Cela me semble être une explication plus plausible que la menace .Net, qui n'existait pas il y a 5 ans.
Quant à l'interface graphique, son aspect dépend uniquement du look & feel que tu définis, et en Java tu peux prendre celui de la plateforme de l'OS sur lequel la JVM tourne. Donc...
[^] # Re: Un nouvel atout pour firefox
Posté par Pierre Tramonson . En réponse au journal Firefox 3.5 est sorti. Évalué à 1.
Oui mais il faut changer de main :/
[^] # Re: Et pourquoi diable
Posté par Pierre Tramonson . En réponse au journal framework ou farmer ?. Évalué à 0.
Si on veut faire de l'objet, on instaure des règles pour définir proprement attributs, méthodes et héritage.
Je n'ai pas l'impression que ce soit le cas en Javascript.
On s'en sort avec des astuces et de la bidouille, mais le langage devrait être nettement plus propre.
[^] # Re: Et pourquoi diable
Posté par Pierre Tramonson . En réponse au journal framework ou farmer ?. Évalué à 1.
Maintenant si ne m'abuse, il n'existe pratiquement rien pour faciliter la vie du développeur et assurer que le code soit un minimum propre.
Là où Java, C# ont des outils, frameworks et règles de code assez bien fournis (je ne parle pas de C, C++ pas vraiment adaptés au web).
Désolé, mais Javascript me semble trop fouilli pour être utilisable correctement, et je maintiens mon parallèle avec PHP d'il y a quelques années.
Mais je veux bien admettre ne pas être au courant de toutes les dernières nouveautés et outils JS :)
[^] # Re: Et pourquoi diable
Posté par Pierre Tramonson . En réponse au journal framework ou farmer ?. Évalué à 2.
Au final on se retrouve avec un langage:
- avec une syntaxe trop permissive
- sans éditeur digne de ce nom (sauf si vous connaissez un éditeur ou plugin éclipse qui vous sort les warnings/erreurs d'exécution JS)
- difficile à débugger (super le débug à coup de alert)
- dont le comportement dépend du navigateur final
- dont le comportement dépend du niveau de sécurité du poste
La situation est même pire que celle de PHP :p
Pourquoi le W3C n'a pas pris les devants en proposant d'intégrer dans HTML quelques fonctionnalités "standard" supplémentaires ?
Actuellement on a déjà des onclick(), onmouseover(), etc...
Pourquoi n'aurait-on pas en natif HTML :
- des fonctions génériques du genre check() sur un champ d'un formulaire, pour vérifier par exemple que ce champ contient tel type de données (cf regexp).
- le même genre de fonctions mais qui t'empêcherait de saisir un caractère d'un type non autorisé dans un champ. Je sais qu'on peut le faire actuellement, mais il faut gérer en plus de la saisie au clavier, le copier/coller...
- une gestion des erreurs sur un formulaire entier, qui te sortirait par exemple la liste des champs ne validant pas la fonction check()
...
Les formulaires JS sont plus que courants actuellement, et ce genre de besoins existe sur tous les sites.
C'est dommage de se faire chier à devoir prendre un framework JS pour ça.
[^] # Re: Enfin !
Posté par Pierre Tramonson . En réponse au journal À mort les arnaques téléphoniques. Évalué à 8.
Ce n'est pas gênant, au contraire, cela permet de changer d'organisation si un imprévu se produit.
Cela n'empêche pas du tout de s'organiser à l'avance. Si vous appréciez un minimum d'organisation et qu'une sortie est prévue au dernier moment, personne ne vous force à y aller.
[^] # Re: et les bibliotheques python ?
Posté par Pierre Tramonson . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 2.
On devrait mettre un disclaimer sur linuxfr indiquant: "attention si vous poster quelque chose concernant Fortran, attendez vous à être sévérement trollés par Ned".
[^] # Re: Antoine SFEIR sur nonobstant mercredi dernier
Posté par Pierre Tramonson . En réponse au journal Hou la menteuse. Évalué à 2.
[^] # Re: Enfin !
Posté par Pierre Tramonson . En réponse au journal Résultat du concours linuxfr. Évalué à 1.
# C'est trop long
Posté par Pierre Tramonson . En réponse au journal [Hadopi] Défense de nos libertés, dernière ligne droite.. Évalué à 10.
# Et bientôt l'arrivée de l'interface graphique sur Ubuntu
Posté par Pierre Tramonson . En réponse au journal GNU Screen + bling bling. Évalué à -6.
# C'est bien...
Posté par Pierre Tramonson . En réponse à la dépêche E17 est annoncé.. Évalué à 7.
[^] # Re: Triste...
Posté par Pierre Tramonson . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 1.
Pour moi ça n'existe pas et ça ne peut pas exister.
[^] # Re: ENFIN ...
Posté par Pierre Tramonson . En réponse à la dépêche Debian GNU/Linux 5.0 : Lenny. Évalué à 5.