> l'auteur de la news est "release manager" chez Mandriva
Et ce n'est pas la première fois que linuxfr accèpte une news de ce "release manager". Mais seulement pour Mandrake/Mandriva. C'est bien de la publicité gratuite.
Il y a quelques années, c'était pire (oui oui). Il y avait des news d'employé de Mandrake pour casser du Red Hat.
Les dépêches concernant des versions mineures de logiciels doivent être. rejetées. LinuxFr n'a pas vocation à être Freshmeat ou le répertoire. FSF/UNESCO.
> si besoin de ne pas lire les dépêches qui ne t'interesses pas.
Le problème n'est pas là. Je n'ai pas dit que la dépêche était sans intérêt, je n'ai pas dit que la dépêche n'avait pas sa place sur linuxfr. Mais que si ce type de dépêche pour Mandriva (deux annonces de beta pour la même distribution) a sa place selon les modérateurs, alors ce même type de dépêche pour d'autres distribution doit aussi avoir sa place.
Je parle de politique "discriminatoire" de linuxfr pour les distributions.
Je trouve marrant que les gens parle de troll à ce sujet. Ce n'est pas un troll car il n'y a que sur linuxfr que ce type de problème existe et depuis longtemps. Ca c'était calmé avec Mandrake ces derniers temps et ça repart avec Mandriva.
Que linuxfr ajouter qu'ils ont un faible pour Mandriva et Debian dans les régles de modération et l'affaire est pliée. Ainsi on sait où on met ses pieds.
> Parce que des gens qui font une distrib populaire ont besoin d'un coup de main.
C'est people maintenant, et en plus c'est de la publicité gratuite pour une boîte commerciale.
> Et puis bon, ce genre de réflexion est vraiment casse couille
Lis pas la suite thread.
> les fans des autres distro n'ont qu'à proposé leur news.
Qui seront systématiquement refusées.
> Je suis sûr que si Pat nous fait une petite news sur la nouvelle slack, elle serait validée.
La question n'est pas là.
Si Pat fait plus d'une news pour des beta de la même slack, seront-elle accèptées ?
La réponse est "non".
Si c'est warly pour Mandriva la réponse est "oui".
Si le but de la news était d'attirer l'attention sur les difficultés de Mandriva, les décrires (par exemple : "besoin d'un développeur spécialisé en bidules") alors je suis d'accord pour qu'une telle news soit accèptée. Et si en fin de news il y a deux lignes avec : "La rc1 de Mandriva 2007 vient de sortir. Tout les infos sont sur http://ici/ " je suis encore d'accord. Mais que si c'est aussi accèpté pour les autres distributions.
Es-ce qu'un modérateur pourrait motiver le passage de cette news ? Surtout que j'ai bien vu passer la news sur la première alpha.
Je croyait que les news sur les beta|test|rc des distributions n'étaient autorisés que pour la première beta|test.
Certe il y a toujours eu l'installeur Debian (et donc la distribution) qui passe systématiquement en première page dès qu'il y a une beta mais c'était une tradition charmante pour se foutre du retard de Debian sur tous ses plannings.
La semaine prochaine il y a une alpha d'openSuSE et d'ubuntu, et une test 3 de Fedora (l'équivalent de cette RC de Mandriva). S'il y a proposition de news, vous devez les autoriser (évidemment si elles sont correctement rédigées).
Perso je m'en fous qu'il y ait une ou plusieurs news pour les betas de distributions. Mais autoriser à une distribution (en fait 2 : Mandriva et Debian) ce que vous refuser par principe à toutes les autres distributions est puant.
Elle est libre. C'est le support qui ne l'est pas. Ca a été discuté sur fsf.org.
Si avec un CD de RHEL tu installes 2 bécanes (ou 15 000) alors que tu n'as souscrit que pour une bécane, tu en as parfaitement le droit. Si Red Hat l'apprend, Red Hat a parfaitement le droit d'arrêter de te donner du support (plus de rhn). Par contre Red Hat ne peut t'interdire d'utiliser ce que tu as déjà (c'est du libre).
Idem pour tout ce que tu récupères via rhn.
Tu peux me croire, ça a été discuté sur la mailing de fsf.org.
> vu qu'il y a une trademark déjà dessus
C'est le même problème avec Ubuntu, Mandriva, etc... Fedora a le même "truc".
Ca n'empêche pas Centos d'exister par exemple.
> rhns RHN Subscription License
J'abuse peut-être mais peux-tu donner le texte de cette licence (ou le mettre sur un site http) et regarder si tu as les sources des programmes sous license "RHN Subscription License".
> Donc soit Red Hat propose une technologie non mature
On peut le voir comme ça. En même temps RHEL est en phase béta. Si à la fin de la phase béta ça "sucks", RHEL n'aura pas cette fonctionnalité.
> soit ils ont patché leur noyau à eux sans que ça remonte pour l'instant en upstream ?
Probablement.
Je crois que pour ce cas spécifique il ne faut pas se prendre la tête.
Red Hat a fait un truc et en était satisfait, ça été envoyé en upstream et accèpté, un peu plus tard ça merde en upstream (ça arrive souvent quand tu élargis l'audience), Linus le vire de la version upstream.
Dans quelques semaines ou mois, Red Hat le proposera à nouveau en upstream, il sera peut-être à nouveau acèpté, et peut-être à nouveau viré quelque temps après.
Ce sont des choses qui arrivent et qui peuvent encore arriver.
> Plus de la moitie des specs de freedsktop ont ete proposees par KDE
Exemple ?
> Je pense meme qu'on est plus proche de 70% mais je ne voudrai pas m'avancer: fichier .desktop, window manager.
Je ne sais plus qui est à l'initiative des fichiers .desktop. Pour le window manager, c'est havoc (développeur Gnome, aussi à l'initiative de freedesktop avec Owen).
> Lis la liste de freedesktop pour voir a quel point KDE est moteur dans ce qui touche a l'interoperabilite.
C'est-à-dire ?
KDE fait des propositions pour que des projets hébergés par freedesktop soient utiles à KDE. C'est normal et très bien venu.
Mais quel projet a été initialisé par KDE pour l'intéropérabilité ?
Spécification pour gestionnaire de fenêtre ? Non.
Dbus ? Non.
HAL ? Non.
Un API multimédia pour tous les desktops ? Non.
Quoi alors ? C'est la seconde fois que je pose la question.
> Tu parles peut-etre du nombre de projets utilisant glib heberges sur freedesktop ? On peut pas vraiment appeler ca developper de l'interoperabilite a partir de cela.
Ben les développeurs gtk/gnome proposent et font des choses. Oui parfois ça utilise glib. Du côté de KDE, il n'y a rien a reprocher car il ne propose rien. Fin de la parenthèse.
> Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne.
Tu veux dire que le dbus de KDE n'a pas de dépendance avec glib ?
Ben tu te trompes. Le dbus de KDE est une surcouche du dbus de freedesktop/gnome qui utilise glib (et il n'y a pas de quoi en faire un fromage). Et cette surcouche (la partie binding C++) est hébergée par freedesktop (où c'est d'ailleurs sa place).
Tu vas peut-être maintenant dire que KDE a sa propre implémentation de HAL ?
Je te donne tout de suite la réponse : Non.
> maintenant deux implementations de la partie client.
Non. KDE a fait une surcouche.
Si je me trompe (je n'ai pas vérifié), indique où sont les sources de l'implémentation de dbus par KDE.
> C'est marrant, les mecs de gstreamers disent au contraire qu'ils ne font pas partie de Gnome et sont un projets independants.
C'est vrai mais ça ne change rien au problème. Gnome essai d'avoir et de développer des solutions utilisables par plusieurs desktops et KDE non.
> Gstreamer n'assure pas la compabilite binaire ni source entre version.
Comme tout le monde ?
Il y a compatibilité entre version X.Y.Z et X.Y.Z+1. pour Y pair. Tout les gstreamer 0.8.* sont compatibles avec gstreamer 0.8.0. Tout les gstreamer 0.10.* sont compatibles avec gstreamer 0.10.0.
L'incompatibilité de gstreamer 0.10 avec 0.8 est connue depuis le début de gstreamer 0.9 (la branche de développement de la version 0.10).
Dis moi si je me trompe, mais KDE 4 ne sera pas compatible avec KDE 3.
> C'est donc impossible de l'utiliser tel quel dans un programme qui lui garantit la compabilite binaire.
Puisque tu parles de dbus. Ben dbus n'avait jusqu'au 17/07/06 aucune garantie de compatibilité source et binaire et aussi entre versions mineurs. Cette compatibilité n'était pas leur soucis. Il y a maintenant un freeze de l'API/ABI pour la version 1.0. Tu as des garanties que cette API/ABI va durer toute la vie de KDE 4 ? NON ! Pas plus que pour l'API de gstreamer 0.10 ou 0.12.
Et je te l'annonce tout de suite pour que tu ne fasses pas un fromage la prochaine fois : gstreamer 0.12 sera incompatible gstreamer 0.10. Par contre personne ne sait quand sortir gstreamer 0.12. Dans un an ou 5, personne ne le sait. D'ailleur il n'y a pas de branche de développement de gstreamer 0.12 (pas de branche 0.11).
Pourtant KDE prend dbus mais refuse gstreamer au motif de la non stabilité de l'API.
On n'est pas dans le deux poids deux mesures ?
Et je ne te parle même pas de HAL où la situation est "pire" (notes les guillemets).
> Si l'utilisateur met a jour sa mandarke et que tout d'un coup, toutes les applications KDE n'ont plus de son parce que gstreamer a ete mis a jour, ce n'es tpas bien
Et si l'utilisateur passe de KDE 3 à KDE 4 ou Qt 3 à Qt 4 ou dbus 0.89 à 0.90, c'est le même problème. Il n'y a rien de nouveau sous le soleil, mais bizarrement les fans de KDE font une fixation sur gstreamer. On nage en plein troll.
Ces problèmes sont à gérer par les gestionnaires de paquet et ils font ça très bien et ils existent pour ça.
> (note que c'est le comportement a l'heure actuelle).
Absolument pas. Sous rpm (et probablement sous apt), la détection de require pour librairie est automatique. Un programme qui a besoin de gstreamer 0.8 aura automatiquement "require libgst*-0.8.so.0". gstreamer 0.8 a automatiquement "provide libgst*-0.8.so.0". gstreamer 0.10 n'a pas "provide libgst*-0.8.so.0" et donc si tu as un programme qui utilise gstreamer 0.8, la mise à jour vers gstreamer 0.10 sera automatiquement refusée a moins que le gestionnaire trouve un gstreamer 0.10 qu'il peut installer en parallèle avec gstreamer 0.8. Ce qui est exactement ce qui se passe aujourd'hui. Donc sur ta bécane tu peux avoir des programmes qui utilisent gstreamer 0.8, pardon gstreamer 0.8.* et gstreamer 0.10.*.
> Donc en gros, tu reproche à KDE de faire progresser KDE ?
Apprends à lire s'il te plait.
J'ai dit :
- "KDE est C++/Qt centrique. Ce n'est pas un reproche, c'est un constat. KDE pense C++, KDE pense Qt, KDE pense KDE. C'est aussi leur force."
> On ne peux pas vraiment dire que Phonon dépends des kdelibs, puisqu'il est inclus dans les kdelibs (comment peut on déprendre de sois même ?)
Donc le retirer de kdelibs ne doit pas poser de problème ?
Ca serait bien pour les applis Qt tu ne trouves pas ?
> KUrl pour les noms de fichier.
Pour gstreamer, l'utilisation de gnome-vfs se fait via un plugin. Tu l'utilises ou non, tu l'installes ou non. Si KDE veut faire un plugin Kurl pour Gstreamer il ne doit pas y avoir de problème (s'il n'existe pas déjà). Il existe aussi un binding de Gstreamer pour C++ (pas finalisé malheureusement).
Voilà la différence. Gstreamer (les développeurs Gnome en général) pense aux autres desktops, pense aux autres languages. Peut-être pas assez, mais beaucoup beaucoup plus que KDE.
Pourtant si Phonon est une brillante idée (ce que je ne crois pas, mais je peux me tromper et l'histoire jugera) alors ça peut intéresser les développeurs de Qt-only, les développeurs de gtk+ (du moins gtkmm) et ça devrait même intéresser les développeurs C++ ligne de commande. Surtout que je viens de voir que Qt4 a fait des efforts pour spliter la librairie.
Mais KDE n'a pensé qu'à KDE. Je ne dis pas que KDE est un "méchant". Ca doit être culturel/historique.
> Ah oui ? Au contraire, les gens de KDE par exemple ont dit "c'est ininteressant pour KDE, on n'adoptera jamais votre truc mais continuez les gars".
Ben Tango ne sera pas un standard.
Il n'empêche que l'effort de tango est à saluer.
Perso, quand je vois une appli KDE, j'ai du mal à comprendre les icones. Probablement car je suis trop habitué à celles de Gnome.
Mais s'il peut y avoir une "barrière" de moins pour que j'utilise des applis KDE sous Gnome, ou que je passe avec moins de difficulté à KDE, alors tant mieux.
> Je suis decu vraiment de voir qu'il y a des gens qui pensent encore cela. KDE est extremement implique dans freedesktop : propositions sur les specifications, feedback sur des implementations, organisations de conferences, etc etc.
Tant mieux si je me suis trompé.
> On peut aussi noter que KDE a adopte une technologie freedesktop, alors meme que la meme techno existait deja chez KDE et que celle de freedesktop n'apportait aucune fonctionnalite specifique sinon une meilleure interoperabilite. Tout le monde a compris que je parle de DBUS.
Dbus a des fonctionnalités que n'avais pas DCOP. Certes KDE pouvait faire évoluer son propre système pour avoir les fonctionnalité de Dbus.
Mais il ne faut pas faire croire que KDE s'est "sacrifié" pour avoir Dbus. Ca les interessait, ils l'ont pris. C'est intelligent.
> J'ai reproche a Tango non pas d'exister mais d'avoir voulu s'imposer sans concertation et d'avoir utilise pour cela freedesktop.
Ben je ne comprend toujours pas.
KDE veut "s'imposer" (notes les guillemets) dans le desktop et Gnome aussi. Il n'y a rien d'anormal et rien à reprocher à ça.
Le problème, est quel est ta définition de "s'imposer".
Si c'est vouloir être largement utilisé et s'en donner les moyens (ici "médiatique) alors je suis d'accord avec toi.
Si c'est *forcer* les autres a utiliser Tango, je ne suis pas d'accord avec toi.
D'ailleurs comment Tango peut *forcer* les autres à utiliser Tango ?
> mais la partie "je suis un standard pour tous les desktops" revendiquees par les auteurs (cf le mail que je cite plus haut) ne deviendra jamais une realite.
Ben tant pis.
Belle démonstration que Tango n'impose rien.
> <<
> Si KDE lance un projet qui peut interesser d'autres desktops, alors qu'ils le mettent sur freedesktop. Ca deviendra peut-être ou non un standard pour tout le monde, mais au moins l'intention sera clairement affichée.
> >>
>
> Comme DCOP ?
??!!??
Le fait est que KDE ne propose pas grand chose. Tu me (nous) dis que KDE bosse avec freedesktop et je m'en félicite.
M'enfin, Gnome (ou des développeurs proches de Gnome) a fait au moins cinq fois plus de propositions. Je ne vais pas te les rappeler.
D'ailleurs je ne connais pas de projet sur freedesktop qui soit à l'initiative de KDE. N'étant pas un expert KDE, si je me trompe n'hésite surtout pas à éclairer ma lanterne.
Il peut y avoir une explication rationnelle à ça. KDE est C++/Qt centrique. Ce n'est pas un reproche, c'est un constat. KDE pense C++, KDE pense Qt, KDE pense KDE. C'est aussi leur force.
Quelque part Gnome est plus disposé a faire des propositions réutilisable sans se "trainer un gros Qt et du C++ inadapté pour faire des bindings".
Pour prendre un exemple chaud, Gnome (des développeurs "fan" de Gnome) fait un serveur multimédia. C'est Gstreamer, ça n'utilise que glib et il y a des bindings. KDE fait un serveur multimédia (un wrapper). C'est phonon, ça demande du C++, Qt, libkde (à confirmer), et les bindings ils n'y ont peut-être même pas pensé.
Ben je comprend que KDE ne pousse pas phonon sur freedesktop car phonon est KDE centrique et ne veut pas être une solution "universelle".
> On pourrait revenir aussi sur DBus qui, bien qu'adopté par KDE, a été imposé par GNOME.
Et comment GNOME a fait ça ?
Avec des pots-de-vin ?
Du chantage ?
Des photos compromettantes ?
GNOME allait attaquer KDE avec des brevets ?
Arrêter de dire des conneries. KDE a pris Dbus car ça leur plaisait. Point barre.
> On pourrait aussi parler de gstreamer
Et KDE n'a pas pris Gstreamer, et il n'y a pas eu de mesure de rétorsion.
Preuve que Gnome n'impose rien à KDE. Preuve que freedesktop n'impose rien à KDE.
Mais si Gnome/Gstreamer/Freedesktop/etc pensent que KDE fait une connerie, ils ont le droit de le dire. Et vice-versa.
Non ?
> c'est une des raisons qui m'ont fait choisir KDE plutôt que GNOME. C'est dommage d'en arriver là.
> En gros, une equipe consistituee principalement de developpeurs de Gnome s'est montee
Où est le problème ?
> a developpe tango sans aucune concertation avec des autres desktop
Il y a toujours des phases où on bossent dans son coin. Surtout à l'initialisation d'un projet et jusqu'en phase alpha voire beta. Tant que tu n'as rien de concret a proposer, c'est comme ça.
Et qu'es-ce que tu entends par "concertation avec les autres desktop" ?
Il y a assurément eu des contacts. Des gens de Gnome, KDE, XFCE, etc qui ont dit : "- c'est interressant, continuez les gars".
Si ceux qui bossent sur Tango n'avait pas un peu l'assurance que leur boulot était utile, ils auraient laissé tomber Tango très vite. Tu ne crois pas ?
S'il voulait faire des icones uniquement pour Gnome, je ne vois pas pourquoi ils sont aller sur freedesktop. Ca serait totalement inutile (Gnome a déjà produit des icones sans freedesktop).
> et est ensuite arrive vers freedesktop en declarant que c'etait un standard que tous les autres projets de bureau
Comment tu fais pour affirmer ça ?
Selon toi pour être un standard de tous les projets de bureau, il suffit de le déclarer. Tu ne trouves pas que c'est un peu léger ?
> C'est vraiment l'oppose des buts et du principe de freedesktop.
freedesktop.org is not a formal standards organization, though some see a need for one that covers some of the areas we are working on. For Linux operating system standards, look at the [WWW]Linux Standard Base project. [WWW]The X.Org Foundation and the [WWW]IETF are other groups that do formal standards. The [WWW]Free Standards Group is one group that publishes "de jure" standards for free software -- freedesktop.org is loosely affiliated the FSG.
Unlike a standards organization, freedesktop.org is a "collaboration zone" where ideas and code are tossed around, and de facto specifications are encouraged. The primary entrée to these discussions is the [WWW]xdg mailing list.
Note: freedesktop.org is not a standards body. The naming of this page is a historical accident, and will take a bit of wiki lifting behind the scenes to fix.
Draft specifications that have pretty good de facto adoption/agreement:
[...]
Il n'y a pas tango dans la liste (pas encore peut-être).
C'est TOI qui vient décréter que Tango est un standard et à partir de là tu fais des raisonnements fumeux.
> Il y a un certain nombre de raison pour KDE de ne pas adopter tango.
Très bien.
Ta critique de Tango/freedesktop est facile. Tu dois être de ces KDE-fans qui vomissent freedesktop, ou du moins voit en freedesktop une "menace" pour KDE, mais n'ose pas l'avouer clairement.
Ca me fait bien rigoler les gens qui critiquent l'implication de Gnome dans freedesktop et surtout quand ça vient de KDE.
KDE ne fait pratiquement aucune proposition au niveau de freedesktop et ne fout pratiquement rien dans freedesktop. OK et très bien. Mais dans ce cas KDE fairait mieux de la fermer sur ce qui est réalisé au niveau de freedesktop.
> Par exemple, le feedback des developpeurs KDE n'a meme pas ete demande
Si KDE était plus impliqué dans freedesktop, la question ne se poserait même pas !
KDE ne fout pratiquement pour freedesktop et tu veux que freedesktop cire les pompes de KDE. Tu ne trouves pas que tu vas un peu loin ?
> Ensuite, Gnome et KDE ont un style d'icone qui est different.
Tango est fait pour unifier les desktops.
Si ce n'est pas possible car la philosophie (vue côté utilisateur) des desktops est trop différente alors tant pis.
Mais l'effort de Tango est très respectable.
> On note regulierement sur la mailing list freedesktop des gens qui arrivent avec des specifications qu'ils veulent pousser pour que tout le monde les adopte, alors qu'ils n'ont pas fait le travail necessaire de concertation, verification de l'historique, interet pour les differents bureaux, etc etc.
Ce boulot la DOIT être fait au niveau de freedesktop. Freedesktop est là pour ça !
Alors S'IL VOUS PLAIT contributeurs de KDE, allez sur freedesktop, contribuez, protestez, gueulez, faites entendre votre voie, mais arrêter de critiquer freedesktop car vous n'y participez pas assez.
> Inutile de dire que dans la plupart des cas, les proposisiont meurent d'elle-meme.
Ce qui est tout à fait normal. Contrairement à ce que tu disais, il ne suffit pas d'être sur freedesktop pour être un standard.
Au-dessus tu annonçais déjà que Tango est un standard uniquement car Tango était sur freedesktop et que TU disait que c'était un standard pour tous les desktop. Tango va peut-être mourir prochainement, je n'en sais rien.
Le rôle de freedeskop n'est pas d'imposer tout ce qu'il héberge.
> Je trouve l'attitude du projet d'autant plus surprenante car il y a des gens dans la communaute Gnome qui savent comment fonctionne l'adoption d'une specification au sein de freedesktop (et qui ont meme fonde freedesktop).
Je me répète : je crois que tu connais mal les objectifs de freedesktop. Pour donner un bon exemple, freedesktop est né pratiquement en même temps que dbus est né. Dbus n'est pas rentré dans freedesktop lorsqu'il a atteint la version 1.0 (version qu'il n'a d'ailleur pas encore atteint).
> Dans le meme ordre d'idee, cairo (moteur de rendu 2D) ne sera pas adopte par KDE/Qt car Qt possede son propre moteur 2D.
Et freedesktop s'en plaint ?
Ben non.
Mais cairo a toute sa place sur freedesktop car ça peut intéresser tous les desktops (sauf KDE).
Si KDE lance un projet qui peut interesser d'autres desktops, alors qu'ils le mettent sur freedesktop. Ca deviendra peut-être ou non un standard pour tout le monde, mais au moins l'intention sera clairement affichée.
Merci d'avoir retrouvé le bug.
Il est maintenant classé en "FC 6 Blocker". Donc la FC6 ne devrait pas sortir avant que ce bug soit corrigé.
> c'est juste une preuve du manque de finition de la distro,
Des preuves de manque de finition tu en trouves dans toute les distributions.
> aucune volonté de faire un truc bien léché.
Ce n'est pas l'objectif de Fedora. Faire un truc "bien léché" prend du temps. Fedora a entre autre pour objectif de faire évoluer vite le logiciel libre.
> Moi j'aurais du mal à avoir confiance en une distro qui ne soigne même pas son processus d'install, même si le bug en question est contournable.
Et qui ne cause aucune perte de données.
Je crois franchement que tu ne connais pas les objectifs de Fedora.
Si tu veux dire que Fedora a des bugs alors OUI Fedora a des bugs. Comme tout le monde, peut-être plus que la moyenne.
Si tu veux dire que Fedora en a rien à foudre des bugs, je dis NON.
Fedora veut corriger le maximum de bug mais tout en restant une distribution dynamique, qui fait avoluer le logiciel libre, qui est attractive pour les développeurs.
Si tu tiens compte de ce contexte, Fedora a un niveau de qualité tout à fait respectable.
Si Fedora voulait corriger tous les bugs, elle serait moins dynamique, attirerait moins de développeur, ferait moins évoluer le logiciel libre. Ca ne serait pas bon pour ses objectifs.
Même pour Fedora il y a des compromis a faire entre évolution et bug. Mais le rapport évolution/bug est plus que respectable. C'est sans aucun doute la plus agressive pour introduire de nouvelles technologies. OUI ça a des effets de bord, mais ça a aussi ses vertues (idem pour les distributions centrées "stabilité").
> Surtout l'hypocrisie en fait. J'aime pas l'hypocrisie. Que ça vienne de Spevack
Fedora a déjà retardé la sortie d'une distribution pour cause de manque de fiabilité. D'ailleurs ça arrive presque toujours.
Fedora a désactivé Selinux dans FC2 (car ce n'est pas en version finale qu'on fait des tests), Fedora a désactivé Pango dans firefox dans FC4, Fedora a désactivé AIGLX dans FC5, etc, etc...
Fedora fait de son mieux pour être fiable MAIS aussi "bleeding edge".
Quand Spevack dit que Fedora veut être fiable, Spevack n'est pas hypocrite !
Vas ici : http://www.redhat.com/archives/fedora-test-list/index.html
C'est pour les tests (pas après la version finale) ! Contrairement à la mailing cooker de mandriva, il n'y a pas de copie de bugzilla !
Durant les releases "test", on grippe à 2000 messages par mois ! Il y a peu de mailing avec un tel débit.
Pour la "test1", trois mois avant la sortie final d'une Fedora, il y a plein de programmes très récents et donc plein plein de bugs. OUI ! Et bien c'est un travail fabuleux qui est fait dans Fedora pour en virer un maximum.
Trois mois (ou même six) avant la sortie d'une Debian stable, il y a peu de programme très récent et donc peu de bug.
Il y a beaucoup plus de bug corrigé par semaine par Fedora que par Debian avant la sortie d'une distribution. Fedora debugge plus que Debian (aussi bien par distribution que par année) ! Et c'est normal ! Pas que Debian soit plus "mauvais" que Fedora mais car Debian prend une voix plus "sage".
Les bugs c'est à la pelle qu'ils sont corrigés chez Fedora. Peut-être pas assez pour toi, mais tu ne peux nier la volonter de débugger et les moyens mise en oeuvre.
Ce que tu reproches à Fedora, c'est un choix. Le choix d'être "bleeding edge", d'évoluer rapidement. Ce choix est très très très largement "avoué". Donc je ne vois pas où est l'hypocrisie dans les propos de Spevack (qui n'a jamais dit que Fedora était la distribution la plus fiable du monde).
Ce que tu demandes, est que Fedora soit stable comme une Debian "stable".
1- Ce n'est pas l'objectif
2- Ce n'est pas possible (ou alors Debian est nul)
Quand tu dis que testing de Debian est plus stable qu'une version finale de Fedora, je n'y crois pas 2 nanosecondes.
Testing de Debian peut passer de Gnome 2.X à Gnome 2.X+2 d'un coup (sans test significatif). Ceci n'arrive pas avec Fedora en final (le freeze en fonctionnalité intervient avec la "test2", puis il y a la "test3" et enfin la final; soit au minimum 2 mois *uniquement* à débugger). Les paquets testing de Debian ne sont pas tous mis au point durant 2 mois. De plus Fedora en final à une branche testing (et ce n'est pas équivalent à "unstable" de Debian) : http://fr.rpmfind.net/linux/fedora/core/updates/testing/
> Surtout l'hypocrisie en fait. J'aime pas l'hypocrisie.
Tu n'es pas un peu hypocrite à ne pas reconnaitre que Fedora/Red Hat a tout à gagné en faisant la distribution la plus fiable possible (évidemment en tenant compte de l'objectif d'être une distribution "bleeding edge").
Moins il y a de bug dans Fedora, moins il y a de bug dans RHEL.
Fedora est beaucoup mieu pour débugger que RHEL. Fedora a infiniment plus de testeur ! Fedora a beaucoup de développeurs externes (ce qui est très loin d'être le cas de RHEL) près à corriger les bugs.
Au moins 90 % des développeurs de Red Hat (ils sont nombreux et non des moindres) utilisent Fedora. Pourquoi tu veux qu'il ne débuggue pas au mieux leur propre système utilisé au quotidien ?
> Fedora, quand ils ont encore un bug isolinux dans FC6 Test2 (qui existe depuis FC5, tests et finale) qui a été corrigé plus vite que leur ombre du côté des gadjos qui font un livecd GParted, on peut se poser des questions sur le processus de création de leur distro.
J'aimerai que tu donnes le rapport du bug d'isolinux dans le bugzilla de redhat. Pour l'instant, je ne sais pas de quoi tu parles et je ne pense pas être le seul.
Merci.
Etrange cette façon qu'on les gens de bondir sur Fedora/Red Hat pour des broutilles : une simple interview. On dirait que vous cherchez un prétexte pour critiquer Fedora/Red Hat.
C'est quoi ton problème ?
Ton problème, c'est l'honnèteté de Red Hat. Oui Fedora est aussi un "laboratoire" pour RHEL.
Ca toujours été ainsi, ça a été annoncé ainsi depuis le début de Fedora (et même avant avec RHLP).
Il y a quelque année Red Hat a eu l'honnèteté de dire que Linux n'était pas prêt pour le desktop. Ca a fait scandale. Aujourd'hui on peut affirmer que Red Hat avait raison.
Mais revenons à nos moutons et maintenant grattes toi un peu le cerveau et demandes toi comment ça peut marcher. Comme Red Hat peut faire du couple Fedora/RHEL un succès.
Si Fedora n'est qu'un truc qui sucks, inutilisable, comment Red Hat fait pour attirer des développeurs sur Fedora ? Développeurs bénévoles mais aussi des payants. Il y a des développeurs d'IBM, Intel, Dell, etc sur les mailing de Fedora.
C'est vrai que Fedora n'est pas fait pour devenir la distribution la plus populaire de la planète. Ce n'est pas l'objectif. http://fedoraproject.org/wiki/Objectives
Core Principles
* Fedora is about the rapid progress of Free and Open Source software and content.
* Fedora believes in the statement "once free, always free".
Si tu veux du stable (stable != fiable), tu dois passer ton chemin.
Objectives of Fedora
* To create a complete general-purpose operating system with capabilities equivalent to competing operating systems, built for and by a community — those who not only consume, but also produce for the good of other community members.
[...]
To produce robust releases approximately every six months, using a release model that takes a balance between both features and time, and allows the development team the flexibility that it needs to ensure code quality, but also ensures that a release does not slip indefinately.
[...]
Non-Objectives of Fedora
* Fedora is not interested in having a slow rate of change, but rather to be innovative.
[...]
> Brian Stevens crache le morceau et avoue le rôle de Fedora.
Il y a quoi de nouveau ?
Ah oui, le monsieur a utilisé le terme de "alpha" et ça ne fait gripper aux rideaux.
> Nous sommes convaincus qu'il y a de meilleures façons de développer des logiciels, alors ce que nous avons fait c'est de se débarrasser de la notion de l'Alpha et nous utilisons Fedora comme cette Alpha.
Déjà, tu dois te demander s'il parle du projet ou de la distribution. Les efforts du projet sont principalement concentré sur le développement. C'est-à-dire avant que la version finale sorte et ceci inclus autour de 3 mois de débuggage.
Alors évidement, il parle du projet et non de la distribution finale (après la finale il ne se passe plus grand chose ; seulement des mises à jours "classiques").
"Alpha" s'utilise pour des logiciels qui ne sont pas stable (nb : stable != fiable). Des logiciels dont l'API peut varier, etc...
Fedora n'est pas stable (stable != fiable) comme l'est RHEL. Donc Fedora peut être considéré comme une version Alpha de RHEL.
Les propos de Brian Stevens sont une excellente nouvelle pour Fedora.
Ca ne surprend pas ceux qui suivent le projet Fedora.
Au début de Fedora, il y avait des produits réservés à RHEL. Ainsi on ne trouvait pas eclipse, ni GFS, etc sous Fedora mais uniquement sous RHEL. C'était principalement des développements fait par les développeurs affecter à RHEL et ils ne voulaient pas s'ajouter la tâche de porter ces/ses développements sous Fedora.
Ces développements sont maintenant sous Fedora !
Il n'y a plus de produit développé par Red Hat qui est spécifique à RHEL.
Excellente nouvelle !
Maintenant il y a tout dans Fedora : system-config-cluster, GFS, Directory Server, etc...
Ainsi les développeurs de RHEL ne bossent plus unique sur RHEL pour RHEL, mais sur Fedora pour Fedora et RHEL. C'est une ouverture supplémentaire et ça permet à qui veut de participer (on est dans le libre). De plus, les développeurs extérieurs préfèrent beaucoup plus Fedora à RHEL (cette dernière est trop figée pour être exitante pour un développeur).
A l'avenir ce qui peut se passer, est que Fedora 12 et RHEL 7 sorte en même temps (ou presque, le packaging de RHEL est plus lourd) ! Avec en gros les mêmes sources ! Avec la même exigence de qualité ! D'ailleurs les outils de test de RHEL sont aujourd'hui à disposition de Fedora (ce n'est pas encore déployé).
Où sera la différence entre Fedora et RHEL ?
Dans le support.
RHEL aura des certifications, des backports pour les corrections de bugs, une ABI/API stable, un support de 7 ans, etc... RHEL sera (comme aujourd'hui) une distribution dédiée aux entreprises.
Fedora sera une distribution plus "dynamique". Fedora sera (comme aujourd'hui) une distribution dédiée aux développeurs.
C'est une excellente nouvelle pour Fedora car il n'y aura plus aucune division entre les développeurs de Fedora et RHEL. Un développeur RHEL sera un développeur Fedora. 100 % des ressources en développement seront affectés sur Fedora. La séparation sera sur le support durant la vie de la distribution.
Bien sûr j'en rajoute. Mais c'est dans cet esprit qu'avance la relation Fedora/RHEL. C'est un fait.
Package selection criteria :
RHEL : Best balance of maturity and features selected based on their appropriateness for commercial deployment.
Fedora : Latest open source community packages. Selected to meet the needs of the open source community and drive rapid technology development.
Donc en quoi "Brian Stevens crache le morceau" ?
La page "objectif" de Fedora et la page comparant Fedora avec RHEL n'ont pratiquement pas bougée depuis le début de Fedora !
On est à la version 5 de Fedora et je me demande comment tu fais pour ne pas être au courrant.
T'as une réponse à me fournir sur ce point ?
To do as much of the development work as possible directly in the upstream packages.
Donc Fedora fait aussi office d'Alpha pour ta putain de distribution chérie qui après peut se flatter d'être techniquement interessante et stable|fiable.
90 % des innovations de Fedora se retrouveront dans ta distribution chérie.
Ne l'oublies pas avant de cracher sur Fedora et ceux (qui évidement ne sont pas que chez Fedora) qui bossent pour faire évoluer le logiciel libre et ne se limitent pas à packager des programmes développés, mise au point, et débuggué par d'autres.
Release early. Release often.
> Le problème, c'est avec l'hypocrisie de certains spécimens comme ce Max Spevack qui est en totale contradiction avec les propos des dirigeants.
Max Spevack ne parle pas de la même chose ! Il parle de fiabilité. Brian Stevens parle du processus de développement, pas de la phase de fiabilisation. Le développement sera fait dans Fedora (la phase Alpha) et plus dans RHEL. Mais évidement Fedora aura (comme aujourd'hui) un phase de fiabilisation (en gros 3 mois avant chaque sortie d'une version finale).
Des travaux sont en cours pour amélioré la fiabilité de Fedora : http://fedoraproject.org/wiki/FedoraTesting
Cette page concerne le testing AVANT la sortie de la version finale et pas APRES. La version finale (celle qui concerne les utilisateurs) n'est pas utilisée pour les tests.
> Sans parler du manque de ressource évident pour le développement de la Fedora
Ca me fait bien rigoler. Red Hat est la plus grosse boite du libre et met plus de développeur sur Fedora que sur RHEL. Et entre deux releases de RHEL, les développeurs RHEL bossent sur Fedora.
C'est du pipo. Fedora en version de développement (les versions test) a toujours des versions développements de Gnome (x.[chiffre impair]).
Ce n'est pas deux semaines avant la sortie de la finale que Fedora est passé de Gnome 2.X à Gnome 2.X+2. Mais de Gnome 2.X.Y à Gnome 2.X+1.0.
[^] # Re: Mandriva et la politique qualité
Posté par clearstream . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à -6.
Et ce n'est pas la première fois que linuxfr accèpte une news de ce "release manager". Mais seulement pour Mandrake/Mandriva. C'est bien de la publicité gratuite.
Il y a quelques années, c'était pire (oui oui). Il y avait des news d'employé de Mandrake pour casser du Red Hat.
C'est beau ? non ?
[^] # Re: RC de distribution en news ?!?
Posté par clearstream . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à 1.
Je n'ai jamais dit que la news n'était pas "valable". Je parle de favoritisme pour Mandriva (et Debian).
> Et comme la plupart du temps, des questions comme celles ci sont plutot une question de ressenti,
Pas d'accord. Il y a des principes qui sont appliqués pour certaines distributions et pas pour d'autres. Ce n'est pas du ressenti, c'est un fait.
> la véritable solution est de prendre sur soit (souvent en essayant de se mettre à la place de l'autre)
Ben mets toi à la place de quelqu'un qui a proposé une news pour une beta d'Ubuntu et qui a essuyé un refus avec en réponse :
http://linuxfr.org/moderateurs/moderation.html
> si besoin de ne pas lire les dépêches qui ne t'interesses pas.
Le problème n'est pas là. Je n'ai pas dit que la dépêche était sans intérêt, je n'ai pas dit que la dépêche n'avait pas sa place sur linuxfr. Mais que si ce type de dépêche pour Mandriva (deux annonces de beta pour la même distribution) a sa place selon les modérateurs, alors ce même type de dépêche pour d'autres distribution doit aussi avoir sa place.
Je parle de politique "discriminatoire" de linuxfr pour les distributions.
Je trouve marrant que les gens parle de troll à ce sujet. Ce n'est pas un troll car il n'y a que sur linuxfr que ce type de problème existe et depuis longtemps. Ca c'était calmé avec Mandrake ces derniers temps et ça repart avec Mandriva.
Que linuxfr ajouter qu'ils ont un faible pour Mandriva et Debian dans les régles de modération et l'affaire est pliée. Ainsi on sait où on met ses pieds.
[^] # Re: RC de distribution en news ?!?
Posté par clearstream . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à -2.
C'est people maintenant, et en plus c'est de la publicité gratuite pour une boîte commerciale.
> Et puis bon, ce genre de réflexion est vraiment casse couille
Lis pas la suite thread.
> les fans des autres distro n'ont qu'à proposé leur news.
Qui seront systématiquement refusées.
> Je suis sûr que si Pat nous fait une petite news sur la nouvelle slack, elle serait validée.
La question n'est pas là.
Si Pat fait plus d'une news pour des beta de la même slack, seront-elle accèptées ?
La réponse est "non".
Si c'est warly pour Mandriva la réponse est "oui".
Si le but de la news était d'attirer l'attention sur les difficultés de Mandriva, les décrires (par exemple : "besoin d'un développeur spécialisé en bidules") alors je suis d'accord pour qu'une telle news soit accèptée. Et si en fin de news il y a deux lignes avec : "La rc1 de Mandriva 2007 vient de sortir. Tout les infos sont sur http://ici/ " je suis encore d'accord. Mais que si c'est aussi accèpté pour les autres distributions.
# RC de distribution en news ?!?
Posté par clearstream . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à -9.
Je croyait que les news sur les beta|test|rc des distributions n'étaient autorisés que pour la première beta|test.
Certe il y a toujours eu l'installeur Debian (et donc la distribution) qui passe systématiquement en première page dès qu'il y a une beta mais c'était une tradition charmante pour se foutre du retard de Debian sur tous ses plannings.
La semaine prochaine il y a une alpha d'openSuSE et d'ubuntu, et une test 3 de Fedora (l'équivalent de cette RC de Mandriva). S'il y a proposition de news, vous devez les autoriser (évidemment si elles sont correctement rédigées).
Perso je m'en fous qu'il y ait une ou plusieurs news pour les betas de distributions. Mais autoriser à une distribution (en fait 2 : Mandriva et Debian) ce que vous refuser par principe à toutes les autres distributions est puant.
[^] # Re: Pondération
Posté par clearstream . En réponse à la dépêche Le projet Debian lance une consultation sur les firmwares non-libres. Évalué à 2.
Elle est libre. C'est le support qui ne l'est pas. Ca a été discuté sur fsf.org.
Si avec un CD de RHEL tu installes 2 bécanes (ou 15 000) alors que tu n'as souscrit que pour une bécane, tu en as parfaitement le droit. Si Red Hat l'apprend, Red Hat a parfaitement le droit d'arrêter de te donner du support (plus de rhn). Par contre Red Hat ne peut t'interdire d'utiliser ce que tu as déjà (c'est du libre).
Idem pour tout ce que tu récupères via rhn.
Tu peux me croire, ça a été discuté sur la mailing de fsf.org.
> vu qu'il y a une trademark déjà dessus
C'est le même problème avec Ubuntu, Mandriva, etc... Fedora a le même "truc".
Ca n'empêche pas Centos d'exister par exemple.
> rhns RHN Subscription License
J'abuse peut-être mais peux-tu donner le texte de cette licence (ou le mettre sur un site http) et regarder si tu as les sources des programmes sous license "RHN Subscription License".
Je n'ai trouvé que ça :
http://www.redhat.com/licenses/rhn.html
http://www.redhat.com/licenses/rhel_france.pdf?country=buyin(...)
Tout celà m'a l'air parfaitement libre (sauf le service).
[^] # Re: SMP alternatives
Posté par clearstream . En réponse au journal RHEL 5 Beta 1 (4.91) est dispo. Évalué à 3.
On peut le voir comme ça. En même temps RHEL est en phase béta. Si à la fin de la phase béta ça "sucks", RHEL n'aura pas cette fonctionnalité.
> soit ils ont patché leur noyau à eux sans que ça remonte pour l'instant en upstream ?
Probablement.
Je crois que pour ce cas spécifique il ne faut pas se prendre la tête.
Red Hat a fait un truc et en était satisfait, ça été envoyé en upstream et accèpté, un peu plus tard ça merde en upstream (ça arrive souvent quand tu élargis l'audience), Linus le vire de la version upstream.
Dans quelques semaines ou mois, Red Hat le proposera à nouveau en upstream, il sera peut-être à nouveau acèpté, et peut-être à nouveau viré quelque temps après.
Ce sont des choses qui arrivent et qui peuvent encore arriver.
[^] # Re: Tango : bof
Posté par clearstream . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 2.
Exemple ?
> Je pense meme qu'on est plus proche de 70% mais je ne voudrai pas m'avancer: fichier .desktop, window manager.
Je ne sais plus qui est à l'initiative des fichiers .desktop. Pour le window manager, c'est havoc (développeur Gnome, aussi à l'initiative de freedesktop avec Owen).
> Lis la liste de freedesktop pour voir a quel point KDE est moteur dans ce qui touche a l'interoperabilite.
C'est-à-dire ?
KDE fait des propositions pour que des projets hébergés par freedesktop soient utiles à KDE. C'est normal et très bien venu.
Mais quel projet a été initialisé par KDE pour l'intéropérabilité ?
Spécification pour gestionnaire de fenêtre ? Non.
Dbus ? Non.
HAL ? Non.
Un API multimédia pour tous les desktops ? Non.
Quoi alors ? C'est la seconde fois que je pose la question.
> Tu parles peut-etre du nombre de projets utilisant glib heberges sur freedesktop ? On peut pas vraiment appeler ca developper de l'interoperabilite a partir de cela.
Ben les développeurs gtk/gnome proposent et font des choses. Oui parfois ça utilise glib. Du côté de KDE, il n'y a rien a reprocher car il ne propose rien. Fin de la parenthèse.
> Par exemple pour dbus, KDE utilise une implementation KDE basee en partie sur Qt pour avoir une bonne integration interne.
Tu veux dire que le dbus de KDE n'a pas de dépendance avec glib ?
Ben tu te trompes. Le dbus de KDE est une surcouche du dbus de freedesktop/gnome qui utilise glib (et il n'y a pas de quoi en faire un fromage). Et cette surcouche (la partie binding C++) est hébergée par freedesktop (où c'est d'ailleurs sa place).
Tu vas peut-être maintenant dire que KDE a sa propre implémentation de HAL ?
Je te donne tout de suite la réponse : Non.
> maintenant deux implementations de la partie client.
Non. KDE a fait une surcouche.
Si je me trompe (je n'ai pas vérifié), indique où sont les sources de l'implémentation de dbus par KDE.
> C'est marrant, les mecs de gstreamers disent au contraire qu'ils ne font pas partie de Gnome et sont un projets independants.
C'est vrai mais ça ne change rien au problème. Gnome essai d'avoir et de développer des solutions utilisables par plusieurs desktops et KDE non.
> Gstreamer n'assure pas la compabilite binaire ni source entre version.
Comme tout le monde ?
Il y a compatibilité entre version X.Y.Z et X.Y.Z+1. pour Y pair. Tout les gstreamer 0.8.* sont compatibles avec gstreamer 0.8.0. Tout les gstreamer 0.10.* sont compatibles avec gstreamer 0.10.0.
L'incompatibilité de gstreamer 0.10 avec 0.8 est connue depuis le début de gstreamer 0.9 (la branche de développement de la version 0.10).
Dis moi si je me trompe, mais KDE 4 ne sera pas compatible avec KDE 3.
> C'est donc impossible de l'utiliser tel quel dans un programme qui lui garantit la compabilite binaire.
Puisque tu parles de dbus. Ben dbus n'avait jusqu'au 17/07/06 aucune garantie de compatibilité source et binaire et aussi entre versions mineurs. Cette compatibilité n'était pas leur soucis. Il y a maintenant un freeze de l'API/ABI pour la version 1.0. Tu as des garanties que cette API/ABI va durer toute la vie de KDE 4 ? NON ! Pas plus que pour l'API de gstreamer 0.10 ou 0.12.
Et je te l'annonce tout de suite pour que tu ne fasses pas un fromage la prochaine fois : gstreamer 0.12 sera incompatible gstreamer 0.10. Par contre personne ne sait quand sortir gstreamer 0.12. Dans un an ou 5, personne ne le sait. D'ailleur il n'y a pas de branche de développement de gstreamer 0.12 (pas de branche 0.11).
Pourtant KDE prend dbus mais refuse gstreamer au motif de la non stabilité de l'API.
On n'est pas dans le deux poids deux mesures ?
Et je ne te parle même pas de HAL où la situation est "pire" (notes les guillemets).
> Si l'utilisateur met a jour sa mandarke et que tout d'un coup, toutes les applications KDE n'ont plus de son parce que gstreamer a ete mis a jour, ce n'es tpas bien
Et si l'utilisateur passe de KDE 3 à KDE 4 ou Qt 3 à Qt 4 ou dbus 0.89 à 0.90, c'est le même problème. Il n'y a rien de nouveau sous le soleil, mais bizarrement les fans de KDE font une fixation sur gstreamer. On nage en plein troll.
Ces problèmes sont à gérer par les gestionnaires de paquet et ils font ça très bien et ils existent pour ça.
> (note que c'est le comportement a l'heure actuelle).
Absolument pas. Sous rpm (et probablement sous apt), la détection de require pour librairie est automatique. Un programme qui a besoin de gstreamer 0.8 aura automatiquement "require libgst*-0.8.so.0". gstreamer 0.8 a automatiquement "provide libgst*-0.8.so.0". gstreamer 0.10 n'a pas "provide libgst*-0.8.so.0" et donc si tu as un programme qui utilise gstreamer 0.8, la mise à jour vers gstreamer 0.10 sera automatiquement refusée a moins que le gestionnaire trouve un gstreamer 0.10 qu'il peut installer en parallèle avec gstreamer 0.8. Ce qui est exactement ce qui se passe aujourd'hui. Donc sur ta bécane tu peux avoir des programmes qui utilisent gstreamer 0.8, pardon gstreamer 0.8.* et gstreamer 0.10.*.
[^] # Re: Tango : bof
Posté par clearstream . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 1.
Apprends à lire s'il te plait.
J'ai dit :
- "KDE est C++/Qt centrique. Ce n'est pas un reproche, c'est un constat. KDE pense C++, KDE pense Qt, KDE pense KDE. C'est aussi leur force."
[^] # Re: Tango : bof
Posté par clearstream . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 0.
Je n'ai pas parlé de Gnome/Phonon mais de Qt/Phonon, gtkmm/Phonon et C++/Phonon.
Et notes que dans ta question il y a la réponse. Ainsi KDE l'a voulu.
[^] # Re: Ikarios.
Posté par clearstream . En réponse au journal DVD Fedora Core 6. Évalué à 1.
Pour l'instant il n'y a que Fedora 6 Test2.
http://fedoraproject.org/wiki/Core/Schedule
Test 3 prévue pour le 13 septembre.
Finale prévue pour le 11 octobre.
[^] # Re: Tango : bof
Posté par clearstream . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à -1.
J'ai dit :
- "un serveur multimédia (un wrapper)"
> On ne peux pas vraiment dire que Phonon dépends des kdelibs, puisqu'il est inclus dans les kdelibs (comment peut on déprendre de sois même ?)
Donc le retirer de kdelibs ne doit pas poser de problème ?
Ca serait bien pour les applis Qt tu ne trouves pas ?
> KUrl pour les noms de fichier.
Pour gstreamer, l'utilisation de gnome-vfs se fait via un plugin. Tu l'utilises ou non, tu l'installes ou non. Si KDE veut faire un plugin Kurl pour Gstreamer il ne doit pas y avoir de problème (s'il n'existe pas déjà). Il existe aussi un binding de Gstreamer pour C++ (pas finalisé malheureusement).
Voilà la différence. Gstreamer (les développeurs Gnome en général) pense aux autres desktops, pense aux autres languages. Peut-être pas assez, mais beaucoup beaucoup plus que KDE.
Pourtant si Phonon est une brillante idée (ce que je ne crois pas, mais je peux me tromper et l'histoire jugera) alors ça peut intéresser les développeurs de Qt-only, les développeurs de gtk+ (du moins gtkmm) et ça devrait même intéresser les développeurs C++ ligne de commande. Surtout que je viens de voir que Qt4 a fait des efforts pour spliter la librairie.
Mais KDE n'a pensé qu'à KDE. Je ne dis pas que KDE est un "méchant". Ca doit être culturel/historique.
Merci d'avoir abondé dans mon sens.
[^] # Re: Tango : bof
Posté par clearstream . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 4.
C'est-à-dire à l'époque de la création de la mailing sur freedesktop (le 26 octobre 2005) :
http://lists.freedesktop.org/archives/tango-artists/
Première contribution KDE quelques jours après (le 31 octoble) :
http://lists.freedesktop.org/archives/tango-artists/2005-Oct(...)
Ca c'est bon esprit ! Que la force soit avec KDE.
Il y a du "KDE touch" dans Tango et c'est tant mieux.
C'est bien mieux que toutes ces "pleunicheries" : "Tango ne nous a pas prévenu, Tango bosse dans son coin, Tango put le Gnome, etc".
La mailing de xdg est sur freedesktop depuis mai 2003 :
http://lists.freedesktop.org/archives/xdg/
[^] # Re: Tango : bof
Posté par clearstream . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à -3.
Ben Tango ne sera pas un standard.
Il n'empêche que l'effort de tango est à saluer.
Perso, quand je vois une appli KDE, j'ai du mal à comprendre les icones. Probablement car je suis trop habitué à celles de Gnome.
Mais s'il peut y avoir une "barrière" de moins pour que j'utilise des applis KDE sous Gnome, ou que je passe avec moins de difficulté à KDE, alors tant mieux.
> Je suis decu vraiment de voir qu'il y a des gens qui pensent encore cela. KDE est extremement implique dans freedesktop : propositions sur les specifications, feedback sur des implementations, organisations de conferences, etc etc.
Tant mieux si je me suis trompé.
> On peut aussi noter que KDE a adopte une technologie freedesktop, alors meme que la meme techno existait deja chez KDE et que celle de freedesktop n'apportait aucune fonctionnalite specifique sinon une meilleure interoperabilite. Tout le monde a compris que je parle de DBUS.
Dbus a des fonctionnalités que n'avais pas DCOP. Certes KDE pouvait faire évoluer son propre système pour avoir les fonctionnalité de Dbus.
Mais il ne faut pas faire croire que KDE s'est "sacrifié" pour avoir Dbus. Ca les interessait, ils l'ont pris. C'est intelligent.
> J'ai reproche a Tango non pas d'exister mais d'avoir voulu s'imposer sans concertation et d'avoir utilise pour cela freedesktop.
Ben je ne comprend toujours pas.
KDE veut "s'imposer" (notes les guillemets) dans le desktop et Gnome aussi. Il n'y a rien d'anormal et rien à reprocher à ça.
Le problème, est quel est ta définition de "s'imposer".
Si c'est vouloir être largement utilisé et s'en donner les moyens (ici "médiatique) alors je suis d'accord avec toi.
Si c'est *forcer* les autres a utiliser Tango, je ne suis pas d'accord avec toi.
D'ailleurs comment Tango peut *forcer* les autres à utiliser Tango ?
> mais la partie "je suis un standard pour tous les desktops" revendiquees par les auteurs (cf le mail que je cite plus haut) ne deviendra jamais une realite.
Ben tant pis.
Belle démonstration que Tango n'impose rien.
> <<
> Si KDE lance un projet qui peut interesser d'autres desktops, alors qu'ils le mettent sur freedesktop. Ca deviendra peut-être ou non un standard pour tout le monde, mais au moins l'intention sera clairement affichée.
> >>
>
> Comme DCOP ?
??!!??
Le fait est que KDE ne propose pas grand chose. Tu me (nous) dis que KDE bosse avec freedesktop et je m'en félicite.
M'enfin, Gnome (ou des développeurs proches de Gnome) a fait au moins cinq fois plus de propositions. Je ne vais pas te les rappeler.
D'ailleurs je ne connais pas de projet sur freedesktop qui soit à l'initiative de KDE. N'étant pas un expert KDE, si je me trompe n'hésite surtout pas à éclairer ma lanterne.
Il peut y avoir une explication rationnelle à ça. KDE est C++/Qt centrique. Ce n'est pas un reproche, c'est un constat. KDE pense C++, KDE pense Qt, KDE pense KDE. C'est aussi leur force.
Gnome pense libgnome, gtk+, pango, glib, cairo, gstreamer, bindings, python, C#, java, etc...
Quelque part Gnome est plus disposé a faire des propositions réutilisable sans se "trainer un gros Qt et du C++ inadapté pour faire des bindings".
Pour prendre un exemple chaud, Gnome (des développeurs "fan" de Gnome) fait un serveur multimédia. C'est Gstreamer, ça n'utilise que glib et il y a des bindings. KDE fait un serveur multimédia (un wrapper). C'est phonon, ça demande du C++, Qt, libkde (à confirmer), et les bindings ils n'y ont peut-être même pas pensé.
Ben je comprend que KDE ne pousse pas phonon sur freedesktop car phonon est KDE centrique et ne veut pas être une solution "universelle".
[^] # Re: Tango : bof
Posté par clearstream . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 2.
Et comment GNOME a fait ça ?
Avec des pots-de-vin ?
Du chantage ?
Des photos compromettantes ?
GNOME allait attaquer KDE avec des brevets ?
Arrêter de dire des conneries. KDE a pris Dbus car ça leur plaisait. Point barre.
> On pourrait aussi parler de gstreamer
Et KDE n'a pas pris Gstreamer, et il n'y a pas eu de mesure de rétorsion.
Preuve que Gnome n'impose rien à KDE. Preuve que freedesktop n'impose rien à KDE.
Mais si Gnome/Gstreamer/Freedesktop/etc pensent que KDE fait une connerie, ils ont le droit de le dire. Et vice-versa.
Non ?
> c'est une des raisons qui m'ont fait choisir KDE plutôt que GNOME. C'est dommage d'en arriver là.
C'est vraiment dommage. Voire con.
[^] # Re: Tango : bof
Posté par clearstream . En réponse à la dépêche Rentrée des classes pour GNOME 2.16. Évalué à 2.
Où est le problème ?
> a developpe tango sans aucune concertation avec des autres desktop
Il y a toujours des phases où on bossent dans son coin. Surtout à l'initialisation d'un projet et jusqu'en phase alpha voire beta. Tant que tu n'as rien de concret a proposer, c'est comme ça.
Et qu'es-ce que tu entends par "concertation avec les autres desktop" ?
Il y a assurément eu des contacts. Des gens de Gnome, KDE, XFCE, etc qui ont dit : "- c'est interressant, continuez les gars".
Si ceux qui bossent sur Tango n'avait pas un peu l'assurance que leur boulot était utile, ils auraient laissé tomber Tango très vite. Tu ne crois pas ?
S'il voulait faire des icones uniquement pour Gnome, je ne vois pas pourquoi ils sont aller sur freedesktop. Ca serait totalement inutile (Gnome a déjà produit des icones sans freedesktop).
> et est ensuite arrive vers freedesktop en declarant que c'etait un standard que tous les autres projets de bureau
Comment tu fais pour affirmer ça ?
Selon toi pour être un standard de tous les projets de bureau, il suffit de le déclarer. Tu ne trouves pas que c'est un peu léger ?
> C'est vraiment l'oppose des buts et du principe de freedesktop.
Lis freedesktop :
http://freedesktop.org/wiki/http://freedesktop.org/wiki/StandardsIl n'y a pas tango dans la liste (pas encore peut-être).
C'est TOI qui vient décréter que Tango est un standard et à partir de là tu fais des raisonnements fumeux.
> Il y a un certain nombre de raison pour KDE de ne pas adopter tango.
Très bien.
Ta critique de Tango/freedesktop est facile. Tu dois être de ces KDE-fans qui vomissent freedesktop, ou du moins voit en freedesktop une "menace" pour KDE, mais n'ose pas l'avouer clairement.
Ca me fait bien rigoler les gens qui critiquent l'implication de Gnome dans freedesktop et surtout quand ça vient de KDE.
KDE ne fait pratiquement aucune proposition au niveau de freedesktop et ne fout pratiquement rien dans freedesktop. OK et très bien. Mais dans ce cas KDE fairait mieux de la fermer sur ce qui est réalisé au niveau de freedesktop.
> Par exemple, le feedback des developpeurs KDE n'a meme pas ete demande
Si KDE était plus impliqué dans freedesktop, la question ne se poserait même pas !
KDE ne fout pratiquement pour freedesktop et tu veux que freedesktop cire les pompes de KDE. Tu ne trouves pas que tu vas un peu loin ?
> Ensuite, Gnome et KDE ont un style d'icone qui est different.
Tango est fait pour unifier les desktops.
Si ce n'est pas possible car la philosophie (vue côté utilisateur) des desktops est trop différente alors tant pis.
Mais l'effort de Tango est très respectable.
> On note regulierement sur la mailing list freedesktop des gens qui arrivent avec des specifications qu'ils veulent pousser pour que tout le monde les adopte, alors qu'ils n'ont pas fait le travail necessaire de concertation, verification de l'historique, interet pour les differents bureaux, etc etc.
Ce boulot la DOIT être fait au niveau de freedesktop. Freedesktop est là pour ça !
Alors S'IL VOUS PLAIT contributeurs de KDE, allez sur freedesktop, contribuez, protestez, gueulez, faites entendre votre voie, mais arrêter de critiquer freedesktop car vous n'y participez pas assez.
> Inutile de dire que dans la plupart des cas, les proposisiont meurent d'elle-meme.
Ce qui est tout à fait normal. Contrairement à ce que tu disais, il ne suffit pas d'être sur freedesktop pour être un standard.
Au-dessus tu annonçais déjà que Tango est un standard uniquement car Tango était sur freedesktop et que TU disait que c'était un standard pour tous les desktop. Tango va peut-être mourir prochainement, je n'en sais rien.
Le rôle de freedeskop n'est pas d'imposer tout ce qu'il héberge.
> Je trouve l'attitude du projet d'autant plus surprenante car il y a des gens dans la communaute Gnome qui savent comment fonctionne l'adoption d'une specification au sein de freedesktop (et qui ont meme fonde freedesktop).
Je me répète : je crois que tu connais mal les objectifs de freedesktop. Pour donner un bon exemple, freedesktop est né pratiquement en même temps que dbus est né. Dbus n'est pas rentré dans freedesktop lorsqu'il a atteint la version 1.0 (version qu'il n'a d'ailleur pas encore atteint).
> Dans le meme ordre d'idee, cairo (moteur de rendu 2D) ne sera pas adopte par KDE/Qt car Qt possede son propre moteur 2D.
Et freedesktop s'en plaint ?
Ben non.
Mais cairo a toute sa place sur freedesktop car ça peut intéresser tous les desktops (sauf KDE).
Si KDE lance un projet qui peut interesser d'autres desktops, alors qu'ils le mettent sur freedesktop. Ca deviendra peut-être ou non un standard pour tout le monde, mais au moins l'intention sera clairement affichée.
[^] # Re: arf
Posté par clearstream . En réponse au journal Fluxbuntu, IceBuntu. Évalué à 1.
Non.
> ou je vais encore me faire moinser à mort ?
Pareil.
[^] # Re: Bashbuntu
Posté par clearstream . En réponse au journal Fluxbuntu, IceBuntu. Évalué à 4.
# Bashbuntu
Posté par clearstream . En réponse au journal Fluxbuntu, IceBuntu. Évalué à 9.
[^] # Re: pas d'accord
Posté par clearstream . En réponse au journal Brian Stevens crache le morceau et avoue le rôle de Fedora.. Évalué à 2.
Merci d'avoir retrouvé le bug.
Il est maintenant classé en "FC 6 Blocker". Donc la FC6 ne devrait pas sortir avant que ce bug soit corrigé.
> c'est juste une preuve du manque de finition de la distro,
Des preuves de manque de finition tu en trouves dans toute les distributions.
> aucune volonté de faire un truc bien léché.
Ce n'est pas l'objectif de Fedora. Faire un truc "bien léché" prend du temps. Fedora a entre autre pour objectif de faire évoluer vite le logiciel libre.
> Moi j'aurais du mal à avoir confiance en une distro qui ne soigne même pas son processus d'install, même si le bug en question est contournable.
Et qui ne cause aucune perte de données.
Je crois franchement que tu ne connais pas les objectifs de Fedora.
Si tu veux dire que Fedora a des bugs alors OUI Fedora a des bugs. Comme tout le monde, peut-être plus que la moyenne.
Si tu veux dire que Fedora en a rien à foudre des bugs, je dis NON.
Fedora veut corriger le maximum de bug mais tout en restant une distribution dynamique, qui fait avoluer le logiciel libre, qui est attractive pour les développeurs.
Si tu tiens compte de ce contexte, Fedora a un niveau de qualité tout à fait respectable.
Si Fedora voulait corriger tous les bugs, elle serait moins dynamique, attirerait moins de développeur, ferait moins évoluer le logiciel libre. Ca ne serait pas bon pour ses objectifs.
Même pour Fedora il y a des compromis a faire entre évolution et bug. Mais le rapport évolution/bug est plus que respectable. C'est sans aucun doute la plus agressive pour introduire de nouvelles technologies. OUI ça a des effets de bord, mais ça a aussi ses vertues (idem pour les distributions centrées "stabilité").
[^] # Re: beta et beta..
Posté par clearstream . En réponse au journal Brian Stevens crache le morceau et avoue le rôle de Fedora.. Évalué à 2.
[^] # Re: pas d'accord
Posté par clearstream . En réponse au journal Brian Stevens crache le morceau et avoue le rôle de Fedora.. Évalué à 3.
Fedora a déjà retardé la sortie d'une distribution pour cause de manque de fiabilité. D'ailleurs ça arrive presque toujours.
Fedora a désactivé Selinux dans FC2 (car ce n'est pas en version finale qu'on fait des tests), Fedora a désactivé Pango dans firefox dans FC4, Fedora a désactivé AIGLX dans FC5, etc, etc...
Fedora fait de son mieux pour être fiable MAIS aussi "bleeding edge".
Quand Spevack dit que Fedora veut être fiable, Spevack n'est pas hypocrite !
Vas ici :
http://www.redhat.com/archives/fedora-test-list/index.html
C'est pour les tests (pas après la version finale) ! Contrairement à la mailing cooker de mandriva, il n'y a pas de copie de bugzilla !
Durant les releases "test", on grippe à 2000 messages par mois ! Il y a peu de mailing avec un tel débit.
Pour la "test1", trois mois avant la sortie final d'une Fedora, il y a plein de programmes très récents et donc plein plein de bugs. OUI ! Et bien c'est un travail fabuleux qui est fait dans Fedora pour en virer un maximum.
Trois mois (ou même six) avant la sortie d'une Debian stable, il y a peu de programme très récent et donc peu de bug.
Il y a beaucoup plus de bug corrigé par semaine par Fedora que par Debian avant la sortie d'une distribution. Fedora debugge plus que Debian (aussi bien par distribution que par année) ! Et c'est normal ! Pas que Debian soit plus "mauvais" que Fedora mais car Debian prend une voix plus "sage".
Les bugs c'est à la pelle qu'ils sont corrigés chez Fedora. Peut-être pas assez pour toi, mais tu ne peux nier la volonter de débugger et les moyens mise en oeuvre.
Ce que tu reproches à Fedora, c'est un choix. Le choix d'être "bleeding edge", d'évoluer rapidement. Ce choix est très très très largement "avoué". Donc je ne vois pas où est l'hypocrisie dans les propos de Spevack (qui n'a jamais dit que Fedora était la distribution la plus fiable du monde).
Ce que tu demandes, est que Fedora soit stable comme une Debian "stable".
1- Ce n'est pas l'objectif
2- Ce n'est pas possible (ou alors Debian est nul)
Quand tu dis que testing de Debian est plus stable qu'une version finale de Fedora, je n'y crois pas 2 nanosecondes.
Testing de Debian peut passer de Gnome 2.X à Gnome 2.X+2 d'un coup (sans test significatif). Ceci n'arrive pas avec Fedora en final (le freeze en fonctionnalité intervient avec la "test2", puis il y a la "test3" et enfin la final; soit au minimum 2 mois *uniquement* à débugger). Les paquets testing de Debian ne sont pas tous mis au point durant 2 mois. De plus Fedora en final à une branche testing (et ce n'est pas équivalent à "unstable" de Debian) :
http://fr.rpmfind.net/linux/fedora/core/updates/testing/
> Surtout l'hypocrisie en fait. J'aime pas l'hypocrisie.
Tu n'es pas un peu hypocrite à ne pas reconnaitre que Fedora/Red Hat a tout à gagné en faisant la distribution la plus fiable possible (évidemment en tenant compte de l'objectif d'être une distribution "bleeding edge").
Moins il y a de bug dans Fedora, moins il y a de bug dans RHEL.
Fedora est beaucoup mieu pour débugger que RHEL. Fedora a infiniment plus de testeur ! Fedora a beaucoup de développeurs externes (ce qui est très loin d'être le cas de RHEL) près à corriger les bugs.
Au moins 90 % des développeurs de Red Hat (ils sont nombreux et non des moindres) utilisent Fedora. Pourquoi tu veux qu'il ne débuggue pas au mieux leur propre système utilisé au quotidien ?
Faut être hypocrite pour penser comme toi.
[^] # Re: pas d'accord
Posté par clearstream . En réponse au journal Brian Stevens crache le morceau et avoue le rôle de Fedora.. Évalué à 1.
J'aimerai que tu donnes le rapport du bug d'isolinux dans le bugzilla de redhat. Pour l'instant, je ne sais pas de quoi tu parles et je ne pense pas être le seul.
Merci.
# T'as quoi sous le crâne ?
Posté par clearstream . En réponse au journal Brian Stevens crache le morceau et avoue le rôle de Fedora.. Évalué à 2.
C'est quoi ton problème ?
Ton problème, c'est l'honnèteté de Red Hat. Oui Fedora est aussi un "laboratoire" pour RHEL.
Ca toujours été ainsi, ça a été annoncé ainsi depuis le début de Fedora (et même avant avec RHLP).
Il y a quelque année Red Hat a eu l'honnèteté de dire que Linux n'était pas prêt pour le desktop. Ca a fait scandale. Aujourd'hui on peut affirmer que Red Hat avait raison.
Mais revenons à nos moutons et maintenant grattes toi un peu le cerveau et demandes toi comment ça peut marcher. Comme Red Hat peut faire du couple Fedora/RHEL un succès.
Si Fedora n'est qu'un truc qui sucks, inutilisable, comment Red Hat fait pour attirer des développeurs sur Fedora ? Développeurs bénévoles mais aussi des payants. Il y a des développeurs d'IBM, Intel, Dell, etc sur les mailing de Fedora.
C'est vrai que Fedora n'est pas fait pour devenir la distribution la plus populaire de la planète. Ce n'est pas l'objectif.
http://fedoraproject.org/wiki/Objectives
Si tu veux du stable (stable != fiable), tu dois passer ton chemin.
> Brian Stevens crache le morceau et avoue le rôle de Fedora.
Il y a quoi de nouveau ?
Ah oui, le monsieur a utilisé le terme de "alpha" et ça ne fait gripper aux rideaux.
> Nous sommes convaincus qu'il y a de meilleures façons de développer des logiciels, alors ce que nous avons fait c'est de se débarrasser de la notion de l'Alpha et nous utilisons Fedora comme cette Alpha.
Déjà, tu dois te demander s'il parle du projet ou de la distribution. Les efforts du projet sont principalement concentré sur le développement. C'est-à-dire avant que la version finale sorte et ceci inclus autour de 3 mois de débuggage.
Alors évidement, il parle du projet et non de la distribution finale (après la finale il ne se passe plus grand chose ; seulement des mises à jours "classiques").
"Alpha" s'utilise pour des logiciels qui ne sont pas stable (nb : stable != fiable). Des logiciels dont l'API peut varier, etc...
Fedora n'est pas stable (stable != fiable) comme l'est RHEL. Donc Fedora peut être considéré comme une version Alpha de RHEL.
Les propos de Brian Stevens sont une excellente nouvelle pour Fedora.
Ca ne surprend pas ceux qui suivent le projet Fedora.
Au début de Fedora, il y avait des produits réservés à RHEL. Ainsi on ne trouvait pas eclipse, ni GFS, etc sous Fedora mais uniquement sous RHEL. C'était principalement des développements fait par les développeurs affecter à RHEL et ils ne voulaient pas s'ajouter la tâche de porter ces/ses développements sous Fedora.
Ces développements sont maintenant sous Fedora !
Il n'y a plus de produit développé par Red Hat qui est spécifique à RHEL.
Excellente nouvelle !
Maintenant il y a tout dans Fedora : system-config-cluster, GFS, Directory Server, etc...
Ainsi les développeurs de RHEL ne bossent plus unique sur RHEL pour RHEL, mais sur Fedora pour Fedora et RHEL. C'est une ouverture supplémentaire et ça permet à qui veut de participer (on est dans le libre). De plus, les développeurs extérieurs préfèrent beaucoup plus Fedora à RHEL (cette dernière est trop figée pour être exitante pour un développeur).
A l'avenir ce qui peut se passer, est que Fedora 12 et RHEL 7 sorte en même temps (ou presque, le packaging de RHEL est plus lourd) ! Avec en gros les mêmes sources ! Avec la même exigence de qualité ! D'ailleurs les outils de test de RHEL sont aujourd'hui à disposition de Fedora (ce n'est pas encore déployé).
Où sera la différence entre Fedora et RHEL ?
Dans le support.
RHEL aura des certifications, des backports pour les corrections de bugs, une ABI/API stable, un support de 7 ans, etc... RHEL sera (comme aujourd'hui) une distribution dédiée aux entreprises.
Fedora sera une distribution plus "dynamique". Fedora sera (comme aujourd'hui) une distribution dédiée aux développeurs.
C'est une excellente nouvelle pour Fedora car il n'y aura plus aucune division entre les développeurs de Fedora et RHEL. Un développeur RHEL sera un développeur Fedora. 100 % des ressources en développement seront affectés sur Fedora. La séparation sera sur le support durant la vie de la distribution.
Bien sûr j'en rajoute. Mais c'est dans cet esprit qu'avance la relation Fedora/RHEL. C'est un fait.
Enfin : https://www.redhat.com/software/rhelorfedora/
Donc en quoi "Brian Stevens crache le morceau" ?
La page "objectif" de Fedora et la page comparant Fedora avec RHEL n'ont pratiquement pas bougée depuis le début de Fedora !
On est à la version 5 de Fedora et je me demande comment tu fais pour ne pas être au courrant.
T'as une réponse à me fournir sur ce point ?
Pour finir, n'oublie pas ça :
http://fedoraproject.org/wiki/Objectives
Donc Fedora fait aussi office d'Alpha pour ta putain de distribution chérie qui après peut se flatter d'être techniquement interessante et stable|fiable.
90 % des innovations de Fedora se retrouveront dans ta distribution chérie.
Ne l'oublies pas avant de cracher sur Fedora et ceux (qui évidement ne sont pas que chez Fedora) qui bossent pour faire évoluer le logiciel libre et ne se limitent pas à packager des programmes développés, mise au point, et débuggué par d'autres.
Release early. Release often.
> Le problème, c'est avec l'hypocrisie de certains spécimens comme ce Max Spevack qui est en totale contradiction avec les propos des dirigeants.
Max Spevack ne parle pas de la même chose ! Il parle de fiabilité. Brian Stevens parle du processus de développement, pas de la phase de fiabilisation. Le développement sera fait dans Fedora (la phase Alpha) et plus dans RHEL. Mais évidement Fedora aura (comme aujourd'hui) un phase de fiabilisation (en gros 3 mois avant chaque sortie d'une version finale).
Des travaux sont en cours pour amélioré la fiabilité de Fedora :
http://fedoraproject.org/wiki/FedoraTesting
Cette page concerne le testing AVANT la sortie de la version finale et pas APRES. La version finale (celle qui concerne les utilisateurs) n'est pas utilisée pour les tests.
[^] # Re: beta et beta..
Posté par clearstream . En réponse au journal Brian Stevens crache le morceau et avoue le rôle de Fedora.. Évalué à 2.
Ca me fait bien rigoler. Red Hat est la plus grosse boite du libre et met plus de développeur sur Fedora que sur RHEL. Et entre deux releases de RHEL, les développeurs RHEL bossent sur Fedora.
[^] # Re: beta et beta..
Posté par clearstream . En réponse au journal Brian Stevens crache le morceau et avoue le rôle de Fedora.. Évalué à 2.
Ce n'est pas deux semaines avant la sortie de la finale que Fedora est passé de Gnome 2.X à Gnome 2.X+2. Mais de Gnome 2.X.Y à Gnome 2.X+1.0.
Ca fait une différence énorme.