J'ai travaillé chez plusieurs éditeurs, notament dans le département assurance qualité, et je peux vous assurer que bien chez nombre d'entre eux des bugs considérés comme non majeurs sont détectés bien avant la sortie du produit, ne sont pas corrigés pour des contraintes de timing ou de coût, et ne sont surtout PAS DOCUMENTES au public, de peur de ternir l'image du produit !
Ca c'est tout a fait normal, a la fois chez les softs proprios et chez les softs libres.
Si tu devais _tout_ corriger avant de sortir une version, tu ne le sortirais jamais ton soft.
Le probleme ici, c'est la maniere dont est gere la QA de bcp de softs libres, ca veut pas dire que c'est super genialement fait chez tous les editeurs de softs proprios non plus.
Alors oui, tous les projets libres ne sont pas égaux, mais globalement, nul ne peut nier que la méthodologie necessaire pour qu'un projet libre puisse vivre est 1000 fois plus contraignante que chez la plupart des éditeurs. Exemples :
- essayer de faire entrer un bout de code non documenté dans un projet digne de ce nom, on peut voir comment on est reçu;
- la notion d'outil de gestion de source (CVS), quasi obligatoire dans le libre, n'est en place que chez très peu d'éditeurs, et encore, pas forcément sur tous les projets;
- la notion de bugzilla, librement accessible, n'est quasiement JAMAIS offerte par les éditeurs;
- essayer de rassembler une communauté sur le dev d'un projet mal écrit et/ou non documenté et/ou pleins de bugs, on alors peut mesurer sa solitude en tant que contributeur.
Alors moi je te le dis clairement que _NON_ un projet libre est pas plus contraignant que chez bcp d'editeurs proprios.
a) Du code non-documente il y en a partout dans le code libre, j'ai fait l'experience avec Mozilla il y a qqe annees de cela, j'en fait encore regulierement des cauchemards. La doc pour developpeurs dans les projets libres c'est dramatiquement inexistant.
b) CVS n'a rien d'obligatoire dans les LL, plein de projets en font un usage intensif, mais plein de projets ne le font pas, et plein d'editeurs proprios utilisent un equivalent aussi bien entendu
c) un bugzilla like a peu pres tout le monde en a un, la difference etant que dans qqe cas du libre il est ouvert, mais c'est pas ca qui va faire que les bugs sont corriges, cf. le bugzilla de Mozilla qui contient des bugs datant de plus d'un an ou deux
d) Demandes aux dev de LL ici combien de gens se sont joints a leurs projets, tu vas etre decu du resultat.
En plus, je crois que le simple fait qu'un developpeur sache que l'on puisse lire son code le pique dans son amour propre et le force a produire plus propre que s'il a l'assurance que seuls des binaires seront distribués.
C'est peut-etre le cas pour certains, mais c'est :
a) tres tres loin d'etre le cas de tous les devs de softs proprio
b) pas ca qui va empecher des mauvais developpeurs ou des developpeurs inexperimentes de faire du code sale, sans doc, ...
Le probleme qu'a mon avis Lucas aborde ici c'est ca :
Bcp de developpeurs du libre(pas ceux des gros projets on s'entend) n'ont aucune idee de ce qu'est la QA. Les tests unitaires, le blackbox et whitebox testing, stress testing, la documentation des interfaces,... sont un terme chinois pour bcp d'entre eux car ils n'ont pas l'experience de gros projets ou ces elements sont essentiels si tu veux arriver au bout.
C'est aussi bien entendu le cas de softs non-proprios, mais ici il s'agit de cibler un probleme qui affecte le libre et qui est en directe contradiction avec le mythe qui veut que les LL soient mieux codes que des equivalents proprios.
[^] # Re: ha ?!??
Posté par pasBill pasGates . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 10.
Ca c'est tout a fait normal, a la fois chez les softs proprios et chez les softs libres.
Si tu devais _tout_ corriger avant de sortir une version, tu ne le sortirais jamais ton soft.
Le probleme ici, c'est la maniere dont est gere la QA de bcp de softs libres, ca veut pas dire que c'est super genialement fait chez tous les editeurs de softs proprios non plus.
Alors oui, tous les projets libres ne sont pas égaux, mais globalement, nul ne peut nier que la méthodologie necessaire pour qu'un projet libre puisse vivre est 1000 fois plus contraignante que chez la plupart des éditeurs. Exemples :
- essayer de faire entrer un bout de code non documenté dans un projet digne de ce nom, on peut voir comment on est reçu;
- la notion d'outil de gestion de source (CVS), quasi obligatoire dans le libre, n'est en place que chez très peu d'éditeurs, et encore, pas forcément sur tous les projets;
- la notion de bugzilla, librement accessible, n'est quasiement JAMAIS offerte par les éditeurs;
- essayer de rassembler une communauté sur le dev d'un projet mal écrit et/ou non documenté et/ou pleins de bugs, on alors peut mesurer sa solitude en tant que contributeur.
Alors moi je te le dis clairement que _NON_ un projet libre est pas plus contraignant que chez bcp d'editeurs proprios.
a) Du code non-documente il y en a partout dans le code libre, j'ai fait l'experience avec Mozilla il y a qqe annees de cela, j'en fait encore regulierement des cauchemards. La doc pour developpeurs dans les projets libres c'est dramatiquement inexistant.
b) CVS n'a rien d'obligatoire dans les LL, plein de projets en font un usage intensif, mais plein de projets ne le font pas, et plein d'editeurs proprios utilisent un equivalent aussi bien entendu
c) un bugzilla like a peu pres tout le monde en a un, la difference etant que dans qqe cas du libre il est ouvert, mais c'est pas ca qui va faire que les bugs sont corriges, cf. le bugzilla de Mozilla qui contient des bugs datant de plus d'un an ou deux
d) Demandes aux dev de LL ici combien de gens se sont joints a leurs projets, tu vas etre decu du resultat.
En plus, je crois que le simple fait qu'un developpeur sache que l'on puisse lire son code le pique dans son amour propre et le force a produire plus propre que s'il a l'assurance que seuls des binaires seront distribués.
C'est peut-etre le cas pour certains, mais c'est :
a) tres tres loin d'etre le cas de tous les devs de softs proprio
b) pas ca qui va empecher des mauvais developpeurs ou des developpeurs inexperimentes de faire du code sale, sans doc, ...
Le probleme qu'a mon avis Lucas aborde ici c'est ca :
Bcp de developpeurs du libre(pas ceux des gros projets on s'entend) n'ont aucune idee de ce qu'est la QA. Les tests unitaires, le blackbox et whitebox testing, stress testing, la documentation des interfaces,... sont un terme chinois pour bcp d'entre eux car ils n'ont pas l'experience de gros projets ou ces elements sont essentiels si tu veux arriver au bout.
C'est aussi bien entendu le cas de softs non-proprios, mais ici il s'agit de cibler un probleme qui affecte le libre et qui est en directe contradiction avec le mythe qui veut que les LL soient mieux codes que des equivalents proprios.