c'est sûr que ça peut surprendre mais je croyais que l'un des bénéfices du libre tout ça c'était qu'on puisse justement subvenir au départ d'un ou du développeur et continuer le projet concerné, par exemple au minimum l'entretenir et fixer les bugs découverts au fur et à mesure ?
Justement, pour pouvoir faire ça, il faut que le code soit maintenable.
À ce titre, au fur et à mesure des engeulades avec Hans Reiser, les devs du kernel ont formulé explicitement des exigences minimales et de bon sens pour l'acceptation d'une grosse nouvelle fonctionalité sensible dans le noyau, car Hans Reiser semblait les ignorer ou les négliger:
- Le code doit respecter les coding standards du noyau (longeur des lignes etc.). Hans Reiser a fait le malin lorsqu'on lui a dit ça: "ouiii mais les coding standards, ça limite ma créativité [...]", mais il devra y passer, comme tout le monde.
- Le code doit utiliser les frameworks & API type vfs (qui eux sont bien maintenus) du kernel lorsqu'ils existent, et ne pas chercher à réinventer la roue "parce que je suis génial et j'ai réinventé l'idée même de filesystem, donc je vais tout refaire: les autres sont des cons, leur framework est pourri".
- Le code doit être relu, corrigé et aprouvé par (au moins) un autre expert du domaine (ça permet de remonter des bugs assez tot, et surtout ça fait une nouvelle personne qui connait assez le code pour le maintenir). C'est assez difficile avec le code d'Hans Reiser car celui-ci conteste la moindre remarque, puis monte sur ses grands cheveaux, puis fait le coup du géni incompris ("tu ne peut pas auditer mon code parce que tu est trop imprégné des concepts des fs classiques"), puis fini en attaque personnelles ("tu es un mauvais developpeur", "tu es un idiot", "tu m'en veut personnellement", ...). Si bien que tout les developpeurs qui ont bien voulu aider Reiser en tenant ce role ont finalement déclaré forfait.
- Le code doit être pret. Hans Reiser prétend que son reiserfs4 est pret depuis plusieurs années (en fait, avant même le 2.6.0 !). Celà dit il a récement publié sa "todolist" de choses importantes à finir pour que reiserfs4 soit au point (selon lui): preuve qu'il ne faut pas le prendre au sérieux quand il dit que c'est pret, et qu'il faut vraiment un tiers expert pour auditer et décider.
- Facultatif (mais ça accèlere grandement l'inclusion), le code peut être soutenu par un "vendor" (une distribution) qui par ex. essai de l'améliorer, le corriger et l'intègre comme fs par défaut. Malheureusement, les diverses distros qui ont soutenu Hans en tenant ce role pour reiserfs3 sont maintenant échaudées (elles l'on vu se dégager de tout intéret et ne pas participer aux corrections de bugs), et aucune ne semble prete à recommencer pour reiserfs4 (bien qu'Andrew Morton ai formulé cette demande au sujet de reiserfs4 sur lkml).
heureusement qu'il n'est pas passé sous un train pendant qu'il s'occupait de reiser3, hein.
C'est tout comme.
Presque aussitot que reiserfs3 a été intégré dans le noyau, Hans est passé à l'implem de reiserfs4 et a cessé de travailler à la correction de bugs. Cette expérience n'encourage pas les developpeurs à relacher les contraintes que j'ai listé ci-dessus. D'autant que la maintenance des filesystems est une des choses les plus sensibles (on peut abandonner le support d'un driver, mais pas d'un fs), et que reiserfs4 veut "revolutionner" beaucoup de concepts acquis (ce qui l'expose encore plus aux problèmes de maintenabilité potentiels).
Sur ce point, je regrette même que le noyau Linux ai une politique trop lâche par rapport à d'autres OS (les *BSD) où, lorsqu'un dev s'est grillé en incluant du mauvais code ou ne le maintenant pas, il est mis en quarantaine et en tout cas, ne peut plus se permettre de publier des nouveautés wizbang tant qu'il n'a pas corrigé les problèmes. Et dans la culture (et la com: les releases/changelogs/, inteviews, mailing-lists...) ils essaient de mettre plus en avant le travail de ceux qui nettoient et corrigent que de ceux qui ajoutent du code (l'inverse de Linux depuis 2.6 quoi).
Bénéfice secondaire, le newbie qui veut se faire admettre (ou qui cherche la gloire ;) va plutôt chercher à trouver et corriger un nouveau bug qu'à implémenter un quarantième scheduler ; et les utilisateurs de ces systèmes, qui sont dès lors plus sensibilisés à ces questions de qualité de code, ne mettent plus la pression sur les devs pour qu'ils intégrent le dernier fs survendu par le marketing narcissique d'un teuton paranoïaque. La culture qualité, c'est tout bon.
Récement Alan Cox et Linus Torvald ont tiré la sonette d'alarme en reprochant aux developpeurs (surtout ceux payés par des fabriquants de matériel) de ne pas s'occuper du bugzilla, et de passer immédiatement à l'implem d'un nouveau truc dès que leur code est accépté. Il a même été question de faire une release uniquement dédiée à la correction du merdier, avec interdiction d'ajouter des fonctionalités.
Je crois qu'il est vraiment temps que Linux devienne exigeant non plus seulement sur la qualité apparement du code, mais sur l'attitude des developpeurs (eg. refuser le nouveau code d'un dev qui a des bugs à corriger, même si ce code parrait bon), pour qu'enfin ces devs se responsabilisent.
En somme, être un logiciel libre n'oblige pas a abandonner tout le travail de qualité logicielle et a accepter n'importe quel patch douteux. C'est le problème avec l'inclusion des produits Reiser...
[^] # Re: De la maintenance..
Posté par herodiade . En réponse à la dépêche Pourquoi Reiser4 n'est toujours pas intégré à Linux. Évalué à 10.
Justement, pour pouvoir faire ça, il faut que le code soit maintenable.
À ce titre, au fur et à mesure des engeulades avec Hans Reiser, les devs du kernel ont formulé explicitement des exigences minimales et de bon sens pour l'acceptation d'une grosse nouvelle fonctionalité sensible dans le noyau, car Hans Reiser semblait les ignorer ou les négliger:
- Le code doit respecter les coding standards du noyau (longeur des lignes etc.). Hans Reiser a fait le malin lorsqu'on lui a dit ça: "ouiii mais les coding standards, ça limite ma créativité [...]", mais il devra y passer, comme tout le monde.
- Le code doit utiliser les frameworks & API type vfs (qui eux sont bien maintenus) du kernel lorsqu'ils existent, et ne pas chercher à réinventer la roue "parce que je suis génial et j'ai réinventé l'idée même de filesystem, donc je vais tout refaire: les autres sont des cons, leur framework est pourri".
- Le code doit être relu, corrigé et aprouvé par (au moins) un autre expert du domaine (ça permet de remonter des bugs assez tot, et surtout ça fait une nouvelle personne qui connait assez le code pour le maintenir). C'est assez difficile avec le code d'Hans Reiser car celui-ci conteste la moindre remarque, puis monte sur ses grands cheveaux, puis fait le coup du géni incompris ("tu ne peut pas auditer mon code parce que tu est trop imprégné des concepts des fs classiques"), puis fini en attaque personnelles ("tu es un mauvais developpeur", "tu es un idiot", "tu m'en veut personnellement", ...). Si bien que tout les developpeurs qui ont bien voulu aider Reiser en tenant ce role ont finalement déclaré forfait.
- Le code doit être pret. Hans Reiser prétend que son reiserfs4 est pret depuis plusieurs années (en fait, avant même le 2.6.0 !). Celà dit il a récement publié sa "todolist" de choses importantes à finir pour que reiserfs4 soit au point (selon lui): preuve qu'il ne faut pas le prendre au sérieux quand il dit que c'est pret, et qu'il faut vraiment un tiers expert pour auditer et décider.
- Facultatif (mais ça accèlere grandement l'inclusion), le code peut être soutenu par un "vendor" (une distribution) qui par ex. essai de l'améliorer, le corriger et l'intègre comme fs par défaut. Malheureusement, les diverses distros qui ont soutenu Hans en tenant ce role pour reiserfs3 sont maintenant échaudées (elles l'on vu se dégager de tout intéret et ne pas participer aux corrections de bugs), et aucune ne semble prete à recommencer pour reiserfs4 (bien qu'Andrew Morton ai formulé cette demande au sujet de reiserfs4 sur lkml).
heureusement qu'il n'est pas passé sous un train pendant qu'il s'occupait de reiser3, hein.
C'est tout comme.
Presque aussitot que reiserfs3 a été intégré dans le noyau, Hans est passé à l'implem de reiserfs4 et a cessé de travailler à la correction de bugs. Cette expérience n'encourage pas les developpeurs à relacher les contraintes que j'ai listé ci-dessus. D'autant que la maintenance des filesystems est une des choses les plus sensibles (on peut abandonner le support d'un driver, mais pas d'un fs), et que reiserfs4 veut "revolutionner" beaucoup de concepts acquis (ce qui l'expose encore plus aux problèmes de maintenabilité potentiels).
Sur ce point, je regrette même que le noyau Linux ai une politique trop lâche par rapport à d'autres OS (les *BSD) où, lorsqu'un dev s'est grillé en incluant du mauvais code ou ne le maintenant pas, il est mis en quarantaine et en tout cas, ne peut plus se permettre de publier des nouveautés wizbang tant qu'il n'a pas corrigé les problèmes. Et dans la culture (et la com: les releases/changelogs/, inteviews, mailing-lists...) ils essaient de mettre plus en avant le travail de ceux qui nettoient et corrigent que de ceux qui ajoutent du code (l'inverse de Linux depuis 2.6 quoi).
Bénéfice secondaire, le newbie qui veut se faire admettre (ou qui cherche la gloire ;) va plutôt chercher à trouver et corriger un nouveau bug qu'à implémenter un quarantième scheduler ; et les utilisateurs de ces systèmes, qui sont dès lors plus sensibilisés à ces questions de qualité de code, ne mettent plus la pression sur les devs pour qu'ils intégrent le dernier fs survendu par le marketing narcissique d'un teuton paranoïaque. La culture qualité, c'est tout bon.
Récement Alan Cox et Linus Torvald ont tiré la sonette d'alarme en reprochant aux developpeurs (surtout ceux payés par des fabriquants de matériel) de ne pas s'occuper du bugzilla, et de passer immédiatement à l'implem d'un nouveau truc dès que leur code est accépté. Il a même été question de faire une release uniquement dédiée à la correction du merdier, avec interdiction d'ajouter des fonctionalités.
Je crois qu'il est vraiment temps que Linux devienne exigeant non plus seulement sur la qualité apparement du code, mais sur l'attitude des developpeurs (eg. refuser le nouveau code d'un dev qui a des bugs à corriger, même si ce code parrait bon), pour qu'enfin ces devs se responsabilisent.
En somme, être un logiciel libre n'oblige pas a abandonner tout le travail de qualité logicielle et a accepter n'importe quel patch douteux. C'est le problème avec l'inclusion des produits Reiser...