Mais c'est "vous" qui polluez systématiquement dlfp avec "gnagna le patch de redhat".
Perso je "pollue" a ce sujet car je pense que la facon dont a ete fait ce patch n'est pas la voie a suivre (au sens integration). Si le libre veut devenir realiste il faut qu'il travaille uni et non avec justement ce genre gueguerre.
Sur Linux c'est courament fait. Il y a des tonnes de trucs que refusent Linus Torvalds qui sont "joyeusement" intégré. Mandrake a demandé l'avis des "core devs" avant d'ajouter supermount qui semble-t-il n'a jamais bien marché et n'a jamais été intégré à Linux ?
Est ce que j'ait dit que j'appreciait aussi ce que je faisait mdk a ce sujet ? Non car pour moi c presque la meme chose qu'a fait RH (l'aspect commercial du "premier qui l'a fait" en moins). Et je pense que si Linus refuse d'integrer des patchs comme celui de supermount c qu'il a ses raisons que seul des core devs peuvent evalues (et c pas des dev classiques qui maitrisent a peine le sujet qui peuvent l'evaluer). Pour preciser, bien que je pense que souvent Linus a tendance a refuser pas mal d'innovations pour vraiment pas grand chose et que RH comme mdk ont des kernels devs bien connus qui peuvent bien integrer "proprement" des patchs non officiels, le principe est pourri car peut facilement entrainer de la part des users (example a la con): "g essaye RH est c'etait tou pourri car y avait pas la detection auto, je suis retourner sous win..."
NON. RedHat et plein d'autres font de même et personne se plaint.
FAUX, je me plaint et je suis pas le seul, les devs kde se plaignent souvent des packages modifies par les distribs (comme de nombreux autres projets: mplayer, ...)
Je ne suis pas d'accord dans le cas d'un distributeur qui n'est pas impliqué dans un projet. Sinon les core devs vont être arselé par suse, mandrake, redhat, debian, slackware, etc... et ils ont autre chose à foutre que de répondre à des besoins spécifiques des distributeurs.
A la base, les distribs n'ont pas a harceler (avec un h) les devs.
Si elles le font, c qu'elles ne doivent pas etre d'accord avec les devs , qui sont normalement les architecte de leurs propres develloppements. Les distribs ne devraient pouvoir que demander des features ou engages des devs impliques dans le projet afin de devellopper leurs besoins. (ce que RH et mdk font generalement et en cela je les respecte)
Redhat a utilisé xft2 et fontconfig pour gnome 2.0 aussi dans la RH8.0 et ce n'était pas dispo officiellement dans Gnome. Ils n'ont pas demandé au projet gnome de bosser sur leur distribe.
Si je me souvient bien, de nombreux core devs gnome bossent chez RH. D'apres toi qui a fait ce (fort bien fait) developpement qui a finit d'ailleurs par etre integre ?
Que dirais-tu si redhat profitait de son influence sur Linux pour changer les orientations du projet ?
Ils l'ont fait au moins pour la libc, gnome et gcc. Maintenant je ne pense pas que cela a ete negatif pour les deux projets.
Que dirais-tu si Alan Cox disait : "mon employeur me dit que pour la prochaine RH10 il faut bosser sur ça et ça.".
Il le dit, de nombreux developpement au niveau noyau qu'il a effectue sont influences par les orientations de RH.
Alsa a fait ses preuves hors de Linux et maintenant Alsa est intégré à Linux 2.6 par exemple. Suse (le principale contributeur alsa et de très loin) n'a pas demandé "svp intégrez Alsa".
hmmm tu devrait relire la lkml alors. Alsa (dont les principaux devs sont payes par suse) a fait cette demande il a y a peu, lorsque le produit etait stable, cela appuye par plusiseurs distribs (suse et mdk en tete) comme gage de stabilite.
Y a-t-il quelqu'un pour dire "scandale suse bosse sur alsa, distribue alsa, alors qu'alsa n'est pas dans le noyau officiel" ? Non, il y a personne pour faire ce reproche.
Heureusement que personne ne se plaint sinon on avancerait pas.
Enfin si tu pense que c ce genre de choses que je pense qu sujet de RH tu te plante bien et tu devrais relire mes commentaires.
Quelle remarque puante. Les sources étaient dispos et il y avait des centaines de testeurs.
Penses-tu que les autres distribs ont le temps de lire les ml de devs des autres ? De plus les sources n'ont etes dispos reeleement qu'a partir d'un certain stade proche de la beta.
Autre chose savait tu que mdk faisait la meme chose dans son coin au meme moment avant que l'on t'en parle ? non, car toi non plus tu ne list pas la ml cooker donc tu n'aurais ete au courant que lors de la livraison de la beta et ce encore si mdk s'en vantait dans l'annonce (ce que RH a fait)
J'ai l'impression que vous avez trouvé un os à rongé car vous n'aimez par redhat.
C faux, je respect bcp RH surtout pour leurs nombreux apports au libre, maintenant je suis realiste sur le fait que c'est une des rares distribs qui montre un aspect commercial aggressif envers les autres (c leur droit, si ils pensent que c comme ca qu'ils vont creuser, maintenant moi je n'aime pas trop leurs methodes)
Mais tout les reproches que tu fais ici sont grotesques.
Relis ce que je dit, au lieu d'interpreter de facon basique ce que je dis. Et evite ce genre de remarques.
[^] # Re: Bon esprit...
Posté par Raphael Junqueira . En réponse à la dépêche Interview de Gaël Duval à propos de Mandrake. Évalué à 1.
Perso je "pollue" a ce sujet car je pense que la facon dont a ete fait ce patch n'est pas la voie a suivre (au sens integration). Si le libre veut devenir realiste il faut qu'il travaille uni et non avec justement ce genre gueguerre.
Sur Linux c'est courament fait. Il y a des tonnes de trucs que refusent Linus Torvalds qui sont "joyeusement" intégré. Mandrake a demandé l'avis des "core devs" avant d'ajouter supermount qui semble-t-il n'a jamais bien marché et n'a jamais été intégré à Linux ?
Est ce que j'ait dit que j'appreciait aussi ce que je faisait mdk a ce sujet ? Non car pour moi c presque la meme chose qu'a fait RH (l'aspect commercial du "premier qui l'a fait" en moins). Et je pense que si Linus refuse d'integrer des patchs comme celui de supermount c qu'il a ses raisons que seul des core devs peuvent evalues (et c pas des dev classiques qui maitrisent a peine le sujet qui peuvent l'evaluer). Pour preciser, bien que je pense que souvent Linus a tendance a refuser pas mal d'innovations pour vraiment pas grand chose et que RH comme mdk ont des kernels devs bien connus qui peuvent bien integrer "proprement" des patchs non officiels, le principe est pourri car peut facilement entrainer de la part des users (example a la con): "g essaye RH est c'etait tou pourri car y avait pas la detection auto, je suis retourner sous win..."
NON. RedHat et plein d'autres font de même et personne se plaint.
FAUX, je me plaint et je suis pas le seul, les devs kde se plaignent souvent des packages modifies par les distribs (comme de nombreux autres projets: mplayer, ...)
Je ne suis pas d'accord dans le cas d'un distributeur qui n'est pas impliqué dans un projet. Sinon les core devs vont être arselé par suse, mandrake, redhat, debian, slackware, etc... et ils ont autre chose à foutre que de répondre à des besoins spécifiques des distributeurs.
A la base, les distribs n'ont pas a harceler (avec un h) les devs.
Si elles le font, c qu'elles ne doivent pas etre d'accord avec les devs , qui sont normalement les architecte de leurs propres develloppements. Les distribs ne devraient pouvoir que demander des features ou engages des devs impliques dans le projet afin de devellopper leurs besoins. (ce que RH et mdk font generalement et en cela je les respecte)
Redhat a utilisé xft2 et fontconfig pour gnome 2.0 aussi dans la RH8.0 et ce n'était pas dispo officiellement dans Gnome. Ils n'ont pas demandé au projet gnome de bosser sur leur distribe.
Si je me souvient bien, de nombreux core devs gnome bossent chez RH. D'apres toi qui a fait ce (fort bien fait) developpement qui a finit d'ailleurs par etre integre ?
Que dirais-tu si redhat profitait de son influence sur Linux pour changer les orientations du projet ?
Ils l'ont fait au moins pour la libc, gnome et gcc. Maintenant je ne pense pas que cela a ete negatif pour les deux projets.
Que dirais-tu si Alan Cox disait : "mon employeur me dit que pour la prochaine RH10 il faut bosser sur ça et ça.".
Il le dit, de nombreux developpement au niveau noyau qu'il a effectue sont influences par les orientations de RH.
Alsa a fait ses preuves hors de Linux et maintenant Alsa est intégré à Linux 2.6 par exemple. Suse (le principale contributeur alsa et de très loin) n'a pas demandé "svp intégrez Alsa".
hmmm tu devrait relire la lkml alors. Alsa (dont les principaux devs sont payes par suse) a fait cette demande il a y a peu, lorsque le produit etait stable, cela appuye par plusiseurs distribs (suse et mdk en tete) comme gage de stabilite.
Y a-t-il quelqu'un pour dire "scandale suse bosse sur alsa, distribue alsa, alors qu'alsa n'est pas dans le noyau officiel" ? Non, il y a personne pour faire ce reproche.
Heureusement que personne ne se plaint sinon on avancerait pas.
Enfin si tu pense que c ce genre de choses que je pense qu sujet de RH tu te plante bien et tu devrais relire mes commentaires.
Quelle remarque puante. Les sources étaient dispos et il y avait des centaines de testeurs.
Penses-tu que les autres distribs ont le temps de lire les ml de devs des autres ? De plus les sources n'ont etes dispos reeleement qu'a partir d'un certain stade proche de la beta.
Autre chose savait tu que mdk faisait la meme chose dans son coin au meme moment avant que l'on t'en parle ? non, car toi non plus tu ne list pas la ml cooker donc tu n'aurais ete au courant que lors de la livraison de la beta et ce encore si mdk s'en vantait dans l'annonce (ce que RH a fait)
J'ai l'impression que vous avez trouvé un os à rongé car vous n'aimez par redhat.
C faux, je respect bcp RH surtout pour leurs nombreux apports au libre, maintenant je suis realiste sur le fait que c'est une des rares distribs qui montre un aspect commercial aggressif envers les autres (c leur droit, si ils pensent que c comme ca qu'ils vont creuser, maintenant moi je n'aime pas trop leurs methodes)
Mais tout les reproches que tu fais ici sont grotesques.
Relis ce que je dit, au lieu d'interpreter de facon basique ce que je dis. Et evite ce genre de remarques.