> et non pas a cause d'une liaison gnome/gstreamer, argument stupide
Qu'es-ce qui te garantit que Qt sera stable durant toute la vie de KDE 4 ?
Qu'es-ce qui te garantit que libjpeg, libxlst, libxml, libsvg, libpcre, libpng, libpgpgme, libnetsnmp, libdbus, libhal, libsmb, et encore une dixaine d'autres librairies non développées par KDE et utilisées par KDE resteront stables durant toute la vie de KDE ?
KDE a-t-il prévu des "phonons" pour toutes ces librairies ?
Non.
Alors pourquoi ce "traitement de faveur" pour Gstreamer ?
A part une raison stupide, je ne vois pas.
> Gstreamer est encore un projet jeune, et qui non seulement ne peut encore garantir de compatibilité binaire, mais meme pas de compatibilité source comme l'a montré le passage 0.8->0.10.
Premièrement, Gstreamer n'a pas cherché à garantir la stabilité de l'API entre la version 0.8 et 0.10. Donc la question de ne pas pouvoir ne se pose pas, car Gstreamer ne voulait pas. Comme KDE ne veut pas garantir la compatibilité entre KDE 3 et KDE 4. La version 0.9 (de développement) était dès l'origine incompatible avec la version 0.8 et c'était prévu avec sa création. La version 0.9 était dès l'origine installable à côté de la version 0.8 (pour conserver une API stable).
Linux est pire que Gstreamer, il n'y a ni ABI et API stable entre versions mineures (x.y.n et x.y.n+1).
Remarquons le culot dont à fait preuve KDE à propos de l'incompatibilité entre gstreamer 0.8 et 0.10 en disant que ça a casser les applis des utilisateurs après une mise à jours. N'importe qu'elle gestionnaire de paquet digne de ce nom aurait refusé de mettre à jour gstreamer 0.8 vers 0.10 si des programmes utilisent gstreamer 0.8 et ne sont pas disponibles en version gstreamer 0.10.
C'est le boulot des gestionnaires de paquet !
Remarquons le culot de KDE de dire que gstreamer 0.10 a introduit des bugs qui n'existaient pas dans gstreamer 0.8. Je suis sûr à 12 000 % que KDE 4 va ajouter des bugs qui n'étaient pas dans KDE 3 et qui ne vont pas être corrigés ni dans la semaine et ni dans le mois de la sortie de KDE 4.
Et quel culot de la part de KDE de critique la maintenance de Gstreamer alors que KDE n'est pas foutu de maintenir Arts qui fait le quart du huitième de ce que fait Gstreamer.
Quand on fait preuve d'un tel niveau de FUD, il y a quelque chose de stupide, de crétin, qui se cache.
> KDE aurait pris Xine par exemple (qui n'est peut-etre pas exempt du probleme de la compatibilité binaire), on aurait crié à la sission, à la fragmentation, et à la duplication inutile d'effort entre KDE et Gnome.
Ben avec Phonon, KDE "garantit" la sission des frameworks durant tout KDE 4. Inutile d'instrumenter Gnome pour le constater.
[^] # Re: Phonon
Posté par clearstream . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à -3.
Gnome à le même cahier des charges.
> et non pas a cause d'une liaison gnome/gstreamer, argument stupide
Qu'es-ce qui te garantit que Qt sera stable durant toute la vie de KDE 4 ?
Qu'es-ce qui te garantit que libjpeg, libxlst, libxml, libsvg, libpcre, libpng, libpgpgme, libnetsnmp, libdbus, libhal, libsmb, et encore une dixaine d'autres librairies non développées par KDE et utilisées par KDE resteront stables durant toute la vie de KDE ?
KDE a-t-il prévu des "phonons" pour toutes ces librairies ?
Non.
Alors pourquoi ce "traitement de faveur" pour Gstreamer ?
A part une raison stupide, je ne vois pas.
> Gstreamer est encore un projet jeune, et qui non seulement ne peut encore garantir de compatibilité binaire, mais meme pas de compatibilité source comme l'a montré le passage 0.8->0.10.
Premièrement, Gstreamer n'a pas cherché à garantir la stabilité de l'API entre la version 0.8 et 0.10. Donc la question de ne pas pouvoir ne se pose pas, car Gstreamer ne voulait pas. Comme KDE ne veut pas garantir la compatibilité entre KDE 3 et KDE 4. La version 0.9 (de développement) était dès l'origine incompatible avec la version 0.8 et c'était prévu avec sa création. La version 0.9 était dès l'origine installable à côté de la version 0.8 (pour conserver une API stable).
Linux est pire que Gstreamer, il n'y a ni ABI et API stable entre versions mineures (x.y.n et x.y.n+1).
Remarquons le culot dont à fait preuve KDE à propos de l'incompatibilité entre gstreamer 0.8 et 0.10 en disant que ça a casser les applis des utilisateurs après une mise à jours. N'importe qu'elle gestionnaire de paquet digne de ce nom aurait refusé de mettre à jour gstreamer 0.8 vers 0.10 si des programmes utilisent gstreamer 0.8 et ne sont pas disponibles en version gstreamer 0.10.
C'est le boulot des gestionnaires de paquet !
Remarquons le culot de KDE de dire que gstreamer 0.10 a introduit des bugs qui n'existaient pas dans gstreamer 0.8. Je suis sûr à 12 000 % que KDE 4 va ajouter des bugs qui n'étaient pas dans KDE 3 et qui ne vont pas être corrigés ni dans la semaine et ni dans le mois de la sortie de KDE 4.
Et quel culot de la part de KDE de critique la maintenance de Gstreamer alors que KDE n'est pas foutu de maintenir Arts qui fait le quart du huitième de ce que fait Gstreamer.
Quand on fait preuve d'un tel niveau de FUD, il y a quelque chose de stupide, de crétin, qui se cache.
> KDE aurait pris Xine par exemple (qui n'est peut-etre pas exempt du probleme de la compatibilité binaire), on aurait crié à la sission, à la fragmentation, et à la duplication inutile d'effort entre KDE et Gnome.
Ben avec Phonon, KDE "garantit" la sission des frameworks durant tout KDE 4. Inutile d'instrumenter Gnome pour le constater.