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".
Et quand le 'truc bien maintenu' est bien pour les developpeurs qui l'ont dévellopé mais absolument pas pour toi , tu fais quoi ? tu fais des gros hack immondes pour que ca fasse ce que tu veux, tu attend que ca change, ou tu "réimplémente a ta sauce" ?
Je ne sais pas si c'est le cas pour reiser4 , mais je connais aucun dévellopeur pro (dont c'est son métier) qui s'amuser a réinventer la roue pour le plaisir.
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.
Le code peut tres bien etre "pret" et quand meme avoir du boulot dessus (optimisation, ajout de fonctionnalité etc ...).
A t'entendre le code de linux (le noyau) n'est pas pret vu qu'il y a quand meme une todo list dessus !
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é.
De l'autre coté ils disent que c'est au distribution de s'occuper de la stabilité du noyau.
Faut savoir ce qu'on veux aussi , soit on veux assurer un support, soit on dis "c'est aux autres de le faire".
Mais on peut pas reprocher aux gens de suivre les lignes de conduites .
Soit on fait des noyaux bien stables, soit on est dans le systeme actuel et dans ce cas on accepte que les gens n'assurent pas le support .
[^] # Re: De la maintenance..
Posté par briaeros007 . En réponse à la dépêche Pourquoi Reiser4 n'est toujours pas intégré à Linux. Évalué à 5.
Et quand le 'truc bien maintenu' est bien pour les developpeurs qui l'ont dévellopé mais absolument pas pour toi , tu fais quoi ? tu fais des gros hack immondes pour que ca fasse ce que tu veux, tu attend que ca change, ou tu "réimplémente a ta sauce" ?
Je ne sais pas si c'est le cas pour reiser4 , mais je connais aucun dévellopeur pro (dont c'est son métier) qui s'amuser a réinventer la roue pour le plaisir.
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.
Le code peut tres bien etre "pret" et quand meme avoir du boulot dessus (optimisation, ajout de fonctionnalité etc ...).
A t'entendre le code de linux (le noyau) n'est pas pret vu qu'il y a quand meme une todo list dessus !
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é.
De l'autre coté ils disent que c'est au distribution de s'occuper de la stabilité du noyau.
Faut savoir ce qu'on veux aussi , soit on veux assurer un support, soit on dis "c'est aux autres de le faire".
Mais on peut pas reprocher aux gens de suivre les lignes de conduites .
Soit on fait des noyaux bien stables, soit on est dans le systeme actuel et dans ce cas on accepte que les gens n'assurent pas le support .