Journal : Mark Shuttleworth : il remet ça
Posté par IsNotGood () le 12 mai 2008
J'aimais bien lire Mark Shuttleworth. Plus maintenant.
Son dernier blog (à cette date :-)) :
http://www.markshuttleworth.com/archives/146
Titre : The Art of Release
Voyons les conneries qu'il y a dedans.
To the best of my knowledge there has never been an "enterprise platform" release delivered exactly on schedule, to the day, in any proprietary or Linux OS.
Bullshit.
Et en passant, heureusement qu'aujourd'hui les distributions entreprise ne se lient pas à un planning, mais à des fonctionnalités à fournir au client.
Not only did it prove that we could execute an LTS release in the standard 6-month timeframe
"Entreprise Ready" veut dire qu'il y a des tonnes d'applications tiers disponibles à la sortie de la distribution. Ça veut aussi dire que la hot line a été formée. Ça veut aussi dire qu'il y a de la documentation de qualité. Pas de la doc qu'on va récupérer ici ou là dans un wiki ou dans un README.txt. Ça veut aussi dire qu'il y a des programmes de formation en place, etc.
Ubuntu 8.04 n'a pas du tout démontré ça. Elle a démontré qu'elle fait comme les autres distributions "communautaires" (Mandriva, Fedora, OpenSuse, etc). Presque rien de plus.
As a result, we can commit that the next LTS release of Ubuntu will be 10.04 LTS, in April 2010.
Et ?
Red Hat ou Novell n'a aucune difficulté pour faire (que) ça !
N'importe qui peut le faire.
Fedora, Mandriva, etc le fait très bien !
Le problème n'est pas de fixer une date et de si tenir, mais de fixer la date où une technologie en développement sera founie prêt à l'emploi pour les entreprises.
Se donner comme objectif seulement une date est ri-di-cu-le.
Par exemple RHEL 6 aura très probablement ext4.
Es-ce Mark Shuttleworth pourrait utiliser sa boule de cristal et nous dire quand ext4 sera prêt pour les entreprises ?
J'en doute, même les développeurs n'ont qu'une vague idée.
En passant, Ubuntu est sorti Firefox en version beta.
Je doute que c'était l'objectif d'Ubuntu 8.04...
Les fonctionnalités ont été adaptés à la date. Où est alors la "prédictibilité" dont il se flatte ? Seulement dans une date. On sait maintenant que l'objectif de la sortie d'une LTS est une date...
This represents one of the most extraordinary, and to me somewhat unexpected, benefits of free software to those who deploy it.
C'est extraordinaire pour le département pub...
This is in my mind a very compelling reason for distributions to focus on distribution - that’s the one thing they do which the upstreams don’t, so they need to invest heavily in that in order to serve as the most efficient conduit of upstream’s work.
Je ne comprend rien...
Ou je comprend mais je ne vois pas où il veut en venir ou ne préfère pas voir où il veut en venir...
There’s one thing that could convince me to change the date of the next Ubuntu LTS: the opportunity to collaborate with the other, large distributions on a coordinated major / minor release cycle. If two out of three of Red Hat (RHEL), Novell (SLES) and Debian are willing to agree in advance on a date to the nearest month, and thereby on a combination of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions, and agree to a six-month and 2-3 year long term cycle, then I would happily realign Ubuntu’s short and long-term cycles around that.
Ben qu'Ubuntu le fasse.
Et pour RHEL c'est très facile.
Le cycle de développement d'une LTS est de 6 mois. Le cycle de développement de RHEL est de 6/9 mois (7 mois pour RHEL 5 entre la première beta et la finale). Donc Ubuntu connait suffisament tôt le noyau que va utiliser la prochaine RHEL, la version Gnome, la toolchain, etc.
Red Hat fournit parfois la date de release finale. Mais même dans ce cas il n'y a pas de garantit.
Il est très probable que la prochaine RHEL 6 soit basée sur F10 (certains pensent que ça va être F9, mais j'en doute). Dès que les premiers plannings de F10 seront dispos, on aura probablement confirmation que RHEL 6 sera basée sur F10. Ceci laisse beaucoup de temps à Ubuntu de s'ajuster (probablement autour de 10 mois). Au "pire", il y a 6 mois entre la première beta RHEL (qui est public) et la finale.
Voyons le ridicule dans la situation.
Ubuntu LTS : 04-2008
RHEL 6 : 04-2009 (peut-être)
Es-ce que Ubuntu va retarder son planning d'un an pour être synchro avec RHEL 6 ?
Ubuntu LTS : 04-2010
Es-ce que Ubuntu va avancer son planning d'un an pour être synchro avec RHEL 6 ?
Es-ce que Ubuntu 10-04 va utiliser la même toolchain que RHEL 6 sortie il y a depuis un an à la sortie d'Ubuntu 10-04 ?
Croyez vous 1 milli-seconde que Red Hat va sortir une RHEL 7 le 04-2010 juste pour faire plaisir à Ubuntu ?
Red Hat ne veut pas s'imposer de date.
Sortir une distribution entreprise juste pour être dans les plannings et faire plaisir au département pub est ridicule.
Red Hat sort une distribution lorsque c'est un plus pour ses clients et que ces plus justifient une nouvelle distribution (migration demandant l'installeur, incompatibilité binaire/source pour les services, etc).
Les (possibles) plus pour le client de RHEL 6 est ext4, FreeIPA, KVM (au-lieu de Xen), etc.
Il y a des nouvelles technologies libre, elles demande parfois une nouvelle distribution.
Mais sortir une nouvelle distribution entreprise à date fixe pour ne pratiquement rien apporter aux clients (seulement s'arracher les cheveux en migration, mise à jour, etc) est ridicule. NB: je parle d'un contexte entreprise et pas hobbyiste.
Un petit exemple, RHEL 5.2 est en beta :
https://www.redhat.com/archives/rhelv5-announce/2008-March/m(...)
Ben oui, passer à Firefox 3 ou OOo 2.3 ne justifie pas une nouvelle distribution (lire le reste de l'annonce, il n'y a pas que ça dans RHEL 5.2 (qui n'est qu'une mise à jour et ne demande qu'un "yum update" qui ne vont pas casser les applis en place, etc)).
Pour avoir OOo 2.3, le client ne veut pas passer à RHEL 6. Il le veut sur ses RHEL 5. Techniquement le passage à OOo 2.3 ne justifie pas une nouvelle distribution.
Ubuntu ne comprend pas ce que veux les entreprises avec le libre.
Les entreprises ne veulent plus de mise à jours juste pour faire plaisir au département pub d'Ubuntu et car ça fait entrer du pognon à Ubuntu. Elles veulent du service ! Elles en ont rien à foutre de changer de distribution si c'est pour 3 fois rien. En tout cas, c'est ainsi pour les serveurs.
Red Hat l'a très bien compris et Red Hat ne vend pas une distribution, mais un service (qui donne accès à toutes les versions d'RHEL). Le client a une souscription pour RHEL, ben il installe une RHEL 4, puis met à jours, s'il le juge utile, vers RHEL 5, puis vers RHEL 6. C'est inclus dans le prix de la souscription (c'est un poil plus compliqué car parfois il n'y a pas correspondance exacte, mais c'est l'esprit). Ce service inclus évidemment le backport des patchs de sécurité pour une version de distribution, les corrections de bug, mais aussi la mise à jours de certaines applis bureautiques comme on l'a vu, ainsi que j'ajout de driver, etc.
Red Hat propose aussi de nouvelle fonctionnalité pour une même version de distribution si ça ne justifie pas une nouvelle distribution.
Avec ce blog, Mark Shuttleworth démontre qu'il n'a pas compris grand chose.
Ou alors en basant sa Ubuntu sur RHEL ou Novell, il veut pouvoir dire : "Ubuntu = RHEL".
Il veut récupérer le boulot de RHEL à moindre coût et le fournir en même temps que RHEL. Il est clair que Red Hat ne va pas lui macher le boulot. Ben oui, Red Hat comme Canonical est une entreprise commerciale qui fait attention à son pognon.
Son dernier blog (à cette date :-)) :
http://www.markshuttleworth.com/archives/146
Titre : The Art of Release
Voyons les conneries qu'il y a dedans.
To the best of my knowledge there has never been an "enterprise platform" release delivered exactly on schedule, to the day, in any proprietary or Linux OS.
Bullshit.
Et en passant, heureusement qu'aujourd'hui les distributions entreprise ne se lient pas à un planning, mais à des fonctionnalités à fournir au client.
Not only did it prove that we could execute an LTS release in the standard 6-month timeframe
"Entreprise Ready" veut dire qu'il y a des tonnes d'applications tiers disponibles à la sortie de la distribution. Ça veut aussi dire que la hot line a été formée. Ça veut aussi dire qu'il y a de la documentation de qualité. Pas de la doc qu'on va récupérer ici ou là dans un wiki ou dans un README.txt. Ça veut aussi dire qu'il y a des programmes de formation en place, etc.
Ubuntu 8.04 n'a pas du tout démontré ça. Elle a démontré qu'elle fait comme les autres distributions "communautaires" (Mandriva, Fedora, OpenSuse, etc). Presque rien de plus.
As a result, we can commit that the next LTS release of Ubuntu will be 10.04 LTS, in April 2010.
Et ?
Red Hat ou Novell n'a aucune difficulté pour faire (que) ça !
N'importe qui peut le faire.
Fedora, Mandriva, etc le fait très bien !
Le problème n'est pas de fixer une date et de si tenir, mais de fixer la date où une technologie en développement sera founie prêt à l'emploi pour les entreprises.
Se donner comme objectif seulement une date est ri-di-cu-le.
Par exemple RHEL 6 aura très probablement ext4.
Es-ce Mark Shuttleworth pourrait utiliser sa boule de cristal et nous dire quand ext4 sera prêt pour les entreprises ?
J'en doute, même les développeurs n'ont qu'une vague idée.
En passant, Ubuntu est sorti Firefox en version beta.
Je doute que c'était l'objectif d'Ubuntu 8.04...
Les fonctionnalités ont été adaptés à la date. Où est alors la "prédictibilité" dont il se flatte ? Seulement dans une date. On sait maintenant que l'objectif de la sortie d'une LTS est une date...
This represents one of the most extraordinary, and to me somewhat unexpected, benefits of free software to those who deploy it.
C'est extraordinaire pour le département pub...
This is in my mind a very compelling reason for distributions to focus on distribution - that’s the one thing they do which the upstreams don’t, so they need to invest heavily in that in order to serve as the most efficient conduit of upstream’s work.
Je ne comprend rien...
Ou je comprend mais je ne vois pas où il veut en venir ou ne préfère pas voir où il veut en venir...
There’s one thing that could convince me to change the date of the next Ubuntu LTS: the opportunity to collaborate with the other, large distributions on a coordinated major / minor release cycle. If two out of three of Red Hat (RHEL), Novell (SLES) and Debian are willing to agree in advance on a date to the nearest month, and thereby on a combination of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions, and agree to a six-month and 2-3 year long term cycle, then I would happily realign Ubuntu’s short and long-term cycles around that.
Ben qu'Ubuntu le fasse.
Et pour RHEL c'est très facile.
Le cycle de développement d'une LTS est de 6 mois. Le cycle de développement de RHEL est de 6/9 mois (7 mois pour RHEL 5 entre la première beta et la finale). Donc Ubuntu connait suffisament tôt le noyau que va utiliser la prochaine RHEL, la version Gnome, la toolchain, etc.
Red Hat fournit parfois la date de release finale. Mais même dans ce cas il n'y a pas de garantit.
Il est très probable que la prochaine RHEL 6 soit basée sur F10 (certains pensent que ça va être F9, mais j'en doute). Dès que les premiers plannings de F10 seront dispos, on aura probablement confirmation que RHEL 6 sera basée sur F10. Ceci laisse beaucoup de temps à Ubuntu de s'ajuster (probablement autour de 10 mois). Au "pire", il y a 6 mois entre la première beta RHEL (qui est public) et la finale.
Voyons le ridicule dans la situation.
Ubuntu LTS : 04-2008
RHEL 6 : 04-2009 (peut-être)
Es-ce que Ubuntu va retarder son planning d'un an pour être synchro avec RHEL 6 ?
Ubuntu LTS : 04-2010
Es-ce que Ubuntu va avancer son planning d'un an pour être synchro avec RHEL 6 ?
Es-ce que Ubuntu 10-04 va utiliser la même toolchain que RHEL 6 sortie il y a depuis un an à la sortie d'Ubuntu 10-04 ?
Croyez vous 1 milli-seconde que Red Hat va sortir une RHEL 7 le 04-2010 juste pour faire plaisir à Ubuntu ?
Red Hat ne veut pas s'imposer de date.
Sortir une distribution entreprise juste pour être dans les plannings et faire plaisir au département pub est ridicule.
Red Hat sort une distribution lorsque c'est un plus pour ses clients et que ces plus justifient une nouvelle distribution (migration demandant l'installeur, incompatibilité binaire/source pour les services, etc).
Les (possibles) plus pour le client de RHEL 6 est ext4, FreeIPA, KVM (au-lieu de Xen), etc.
Il y a des nouvelles technologies libre, elles demande parfois une nouvelle distribution.
Mais sortir une nouvelle distribution entreprise à date fixe pour ne pratiquement rien apporter aux clients (seulement s'arracher les cheveux en migration, mise à jour, etc) est ridicule. NB: je parle d'un contexte entreprise et pas hobbyiste.
Un petit exemple, RHEL 5.2 est en beta :
https://www.redhat.com/archives/rhelv5-announce/2008-March/m(...)
* Laptop and Desktop Enhancement
+ Suspend and Hibernate improvements
+ Re-base of the top Desktop applications
- Evolution 2.12.3
- Firefox 3
- OpenOffice 2.3.0
- Thunderbird 2.0
+ Updated graphics driversBen oui, passer à Firefox 3 ou OOo 2.3 ne justifie pas une nouvelle distribution (lire le reste de l'annonce, il n'y a pas que ça dans RHEL 5.2 (qui n'est qu'une mise à jour et ne demande qu'un "yum update" qui ne vont pas casser les applis en place, etc)).
Pour avoir OOo 2.3, le client ne veut pas passer à RHEL 6. Il le veut sur ses RHEL 5. Techniquement le passage à OOo 2.3 ne justifie pas une nouvelle distribution.
Ubuntu ne comprend pas ce que veux les entreprises avec le libre.
Les entreprises ne veulent plus de mise à jours juste pour faire plaisir au département pub d'Ubuntu et car ça fait entrer du pognon à Ubuntu. Elles veulent du service ! Elles en ont rien à foutre de changer de distribution si c'est pour 3 fois rien. En tout cas, c'est ainsi pour les serveurs.
Red Hat l'a très bien compris et Red Hat ne vend pas une distribution, mais un service (qui donne accès à toutes les versions d'RHEL). Le client a une souscription pour RHEL, ben il installe une RHEL 4, puis met à jours, s'il le juge utile, vers RHEL 5, puis vers RHEL 6. C'est inclus dans le prix de la souscription (c'est un poil plus compliqué car parfois il n'y a pas correspondance exacte, mais c'est l'esprit). Ce service inclus évidemment le backport des patchs de sécurité pour une version de distribution, les corrections de bug, mais aussi la mise à jours de certaines applis bureautiques comme on l'a vu, ainsi que j'ajout de driver, etc.
Red Hat propose aussi de nouvelle fonctionnalité pour une même version de distribution si ça ne justifie pas une nouvelle distribution.
Avec ce blog, Mark Shuttleworth démontre qu'il n'a pas compris grand chose.
Ou alors en basant sa Ubuntu sur RHEL ou Novell, il veut pouvoir dire : "Ubuntu = RHEL".
Il veut récupérer le boulot de RHEL à moindre coût et le fournir en même temps que RHEL. Il est clair que Red Hat ne va pas lui macher le boulot. Ben oui, Red Hat comme Canonical est une entreprise commerciale qui fait attention à son pognon.
> Lire le journal (81 commentaires, moyenne: 3,6).
Vous avez demandé le commentaire #930762.
Run by 
Cette page a été générée par Templeet en 0.0703s (dont 0.0073 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
L'upstream
Moi ce qui m'inquiète beaucoup dans cette histoire c'est le manque total de considération pour "l'upstream".
Ce monsieur veut faire pression sur l'upstream - car c'est de cela qu'il s'agit en demandant à toutes les distros de releaser en même temps - pour aligner les dates de release.
Cela n'a aucun sens sur le plan technique ou humain, certains projets ne sont pas en mesure de définir une date pour leur prochaine version, et je ne crois pas que "ubuntu sort dans deux mois" soit un critère pertinent lorsqu'on veut savoir ce que contiendra la prochaine version.
Mais ça va plus loin : il semble totalement ignorer qu'une distribution est précisément un ensemble de logiciels qui viennent de l'"upstream". Cette manière de présenter son travail comme la partie la plus importante du processus de production d'un logiciel me semble tout à fait déplacée.
Alors je sais, on est sûrement beaucoup de développeurs à sous-estimer et par conséquent mépriser un peu la difficulté et l'importante du travail du packageur.
Mais c'est quand même pas lui qui écrit le logiciel aux dernières nouvelles, donc je vois pas de quel droit il voudrait décider des dates de sortie...
[^]Re: L'upstream
Si on s'intéresse au cas de X.Org, ce qui manque pour accélérer les releases, c'est quelqu'un payé pour ça, un "release manager" : une personne qui puisse passer un certain temps à enlever les bugs critiques qui n'intéressent personne d'autre, et backporter certains bouts de code.
Jusqu'à maintenant, les release manager de X.Org ont étés des employés de RedHat, Intel et Nokia. Donc effectivement il aurait une occasion de joindre l'acte à la parole, mais il ne le fait pas.
[^]Re: L'upstream
Zut, ça veut pas passer à "Évalué à 11".
100% d'accord, c'est là qu'est le fond du problème. C'est pas parce que ce sont les distributions qui sont en contact direct avec les utilisateurs finaux qu'ils faut qu'elles oublient qu'elles ne sont pas beaucoup plus qu'un relai.
(Oserais-je la comparaison avec les artistes et les maisons d'édition ? Non, tout de même)
Et pourtant, je suis packageur.
[^]Re: L'upstream
J'ai pas vu passer beaucoup d'ubunteros, donc je vais me faire l'avocat du diable mais je me désensibilise complètement de l'histoire (vu que sous freebsd ça se passe pas tout à fait comme ça et qu'on s'en fout un peu plus des dates de release).
Bref, je pense que tu extrapoles un peu et je crois qu'il connait l'importance des développeurs, c'est grâce à eux qu'il fait du business.
Si je suis d'accord pour dire qu'il faut faire gaffe aux dérives (de pression), je ne suis pas d'accord pour tapper n'importe comment sur les idées. Si RH,ubuntu,debian... s'accordent pour une date de release, sans exercer de pression, il y a de fortes chances pour que les développeurs poffinent volontiers leur logiciel pour la date prévu.
le problème peut se résumer ainsi :
"certains projets ne sont pas en mesure de définir une date" et donc, pour "certains", ceux pour qui de toutes façon cela ne changera rien qu'ils s'alignent ou non, tu rejettes le tout ?
[^]Re: L'upstream
J'ai pas vu passer beaucoup d'ubunteros
Et pour cause:
http://blog.kagou.fr/post/2008/05/12/Appel-du-pied#c1410
[^]Re: L'upstream
Je continue avec ces nouvelles infos,
"Se coordonner signifie se mettre d'accord sur les différentes versions des composants majeurs/critiques d'un système d'exploitation comme le noyau, le compilateur etc. Cela permettrait un meilleur travail et remonté de bogues avec les projets upstream"
C'est pas faux, on blinde de bug report et de patch une certaine version du noyau par exemple (idem avec gnome etc.) je vois de l'aide mais pas de pression.
"Tout synchroniser retirerait certains des gros avantages du libre : la diversité et la possibilité de sélectionner la distribution en fonction de ses particularité et des choix qui y ont été faits."
Ça, je ne comprend pas. Déjà en soit je ne vois pas ce qu'implique la synchronisation, mais en plus il a l'air de dire que : Ubuntu sort en février, on l'install, red hat sort en avril, on passe à red hat, en juillet s'en est une autre... ? une distrib en général on est fidèle, on la garde des années, non ?
[^]Re: L'upstream
> C'est pas faux, on blinde de bug report et de patch une certaine version du noyau par exemple (idem avec gnome etc.) je vois de l'aide mais pas de pression.
Si les distributions faisaient correctement leur boulot, il n'y aurait même pas à évoquer cette idée.
FedoraProject a fait le choix de travailler directement en upstream, tout bogue corrigé dans Fedora l'est automatiquement en upstream, c'est une politique définie au niveau du projet. Gentoo, et dans une moindre mesure Novell ont une politique semblable.
A l'exception de quelques paquets, Ubuntu est un très mauvais élève concernant les remontées en upstream. Au bout de 4 ans, ils ont encore du mal à faire des remontées vers Debian, mais c'est encore pire pour les remontées en upstream.
La réponse d'Ubuntu est désarmante à ce sujet: ils recommandent aux développeurs de venir suivre directement les patchs chez eux ! Vous imaginez si tout les développeurs devaient fouiller les bugzilla (et autre clones propriétaires) de toutes les distributions ? Vous imaginez le temps perdu à distinguer les patchs spécifiques à tel distribution, à corriger les patchs gruik-esque de certains empaqueteurs ? Sans compter qu'un bogue corrigé dans une distribution pourrait bénéficier à tous ?
Hein, la meilleure façon de mutualiser les ressources c'est de travailler main dans la main avec upstream et non pas dans un rapport de force.
Si tu es développeur d'un projet libre, tu apprécierais qu'un "metteur en boite" décide pour toi d'un calendrier sur deux ans avec des objectifs précis sans te demander ton avis ? Tu ne vois pas où est la pression dans cette proposition ?
On te parle pas de blinder une version précise de rapports de bogues ou de patchs (faudrait déjà qu'Ubuntu s'améliore grandement en ce domaine) mais carrément d'imposer une feuille de route aux développeurs. Il parle bien de coordonner les différents projets et pas de prendre une version au pif pour la tester à mort.
De plus, en focalisant toute la force de travail sur telle version, tu ralentiras automatiquement le développement du logiciel
Canonical a refuse Debian Common Core qui proposait strictement la même chose au niveau des distributions dérivées de Debian. Et maintenant, il veut faire la même chose avec RHEL et SuSE deux distributions complétement différentes?
La force du libre, c'est que chacun est libre d'innover, de casser des modules si nécessaire. Si tu imposes à un cadre trop rigide, les contributeurs se feront chier comme des rats morts, ça n'avancera plus.
Les distributions n'ont pas forcément les mêmes objectifs, si la proposition de Shuttleworth aait été mise en application:
* pas de gvfs et de PA car on ne casse plus rien à l'approche de la release. Bref, on se coltine des merdes comme Gnome-vfs et ESD pour des années de plus.
* Fedora 9 (base de RHEL 6) n'aurait pas été libre de travailler pour linux 2.6.25 et xserver 1.5 pour privilégier les versions "sélectionnés", retardant d'autant le développement de ces logiciels. Le développement de NetworkManager 0.7 aurait été abandonné pour maintenir la version "stable" alors que c'est une impasse. Brisant le contrat entre Fedora et la communauté qui consiste à faire avancer le logiciel libre.
* Debian devrait sortir une version qui ne correspond pas à ses propres critères de qualité.
Au final, ça reviendrait aux autres distributions de caler leurs objectifs sur ceux d'Ubuntu au détriment de leurs siens. Je ne crois pas que le logiciel libre y soit gagnant.
> une distrib en général on est fidèle, on la garde des années, non ?
Quel est le rapport avec la discussion ?
[^]Re: L'upstream
> FedoraProject a fait le choix de travailler directement en upstream
http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
> A l'exception de quelques paquets, Ubuntu est un très mauvais élève concernant les remontées en upstream.
On peut aussi noter qu'Ubuntu a une mailing pour les développeurs Ubuntu (Canonical principalement), et une mailing pour les autres développeurs...
> ils recommandent aux développeurs de venir suivre directement les patchs chez eux !
C'est prévu :-)
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Point of contact for upstream developers to reach Ubuntu developers
> tu apprécierais qu'un "metteur en boite" décide pour toi d'un calendrier sur deux ans
Je n'image même pas comment Red Hat ou Novell voit l'"invitation" d'Ubuntu a sortir leur prochaine distribution entreprise en avril 2010...
Ces derniers sont toujours hyper discrets sur les dates des prochaines releases entreprises. Pas forcément car c'est un secret, mais car ils ne savent pas !
Ils ont seulement un vague idée.
> Fedora 9 (base de RHEL 6)
Même entre Fedoraiste, on se battaille pour savoir si RHEL 6 va être basée sur F9 ou sur F10 :-)
A la sortie de F8, Red Hat ne le savait pas.
Jusqu'à maintenant on ne sait toujours pas.
Certains (dont je fais parti) pensent que ça va être F10 car les développeurs Red Hat sont très occupés actuellement et que ext4/kvm ne sont pas prêts encore.
D'autres comme GeneralZod passent que c'est F9.
Je ne serait pas étonné que du côté de Red Hat il ne savent pas encore de façon sûr...
Les paris sont ouverts !
[^]Re: L'upstream
On est déjà même pas d'accord sur comment nommer RedHat Entreprise Linux. ;-)
It is never correct to abbreviate “Red Hat Enterprise Linux” as “RHEL”.
http://www.redhatmagazine.com/2008/02/04/tips-and-tricks-rhe(...)
> Certains (dont je fais parti) pensent que ça va être F10 (..)
Je pense qu'ils ont déjà commencé à bosser mais ça n'étonnerait pas qu'il reparte sur une base Fedora 10.
Mais entre la sortie prochaine de RHEL 5.2, le fait que RH n'ait pas ralenti la cadence dans Fedora 9, ton raisonnement tient parfaitement la route.
Une chose est sûre, RH ne synchronisera pas son calendrier sur celui de Mark Shuttleworth. "Wake me up when it's done".
[^]Re: L'upstream
Moi je pari sur Fedora 10
Pour avoir un KDE 4.1 complet et pas un truc bancale mélange de KDE3 et KDE 4.0
Pour avoir un GNOME plus uniforme (suppression de libgnomeprint, gnome-vfs, ....)
Une meilleure intégration de pulseaudio.
Un portage de LTSP fonctionnel
Pour avoir un Xorg finalisé, les drivers et les utilitaires de configuration qui vont bien avec.
Pour proposer un ext4 utilisable
Pour avoir un JDK opensource officiel
Bref... Fedora 9 est une distrib de transition, pas utilisable sur le long terme...
[^]Re: L'upstream
Ajoutons aussi KVM dont les travaux sont à 2 / 3 terminé.
> Pour proposer un ext4 utilisable
Il me semble qu'il est clairement non raisonnable de proposer ext4 pour RHEL si ext4 n'a pas subit l'épreuve des utilisateurs via F10 (période béta + 3 ou 4 mois après la finale).
E2fsck n'est même pas encore finit pour ext4 (une mise à jour est prévue pour F9).
Il y a un évènement intéressant, c'est le prochain FUDCon. Ou le prochain Red Hat Summit. Ils auront lieu en même temps. L'occasion me semble excellente pour Red Hat d'annoncer que RHEL 6 va être basée sur F10.
> Pour avoir un JDK opensource officiel
Red Hat fait le portage pour RHEL 5.2.
[^]Re: L'upstream
>> une distrib en général on est fidèle, on la garde des années, non ?
>Quel est le rapport avec la discussion ?
C'est juste que la personne que je cite disais que cela empêcherai de choisir sa distribution ou quelquechose dans le genre. Enfin pas important.
"tout bogue corrigé dans Fedora l'est automatiquement en upstream,"
Ils maitrisent tous les cvs ? Ou ils forcent juste l'incorporation ?
Non, sérieusement je ne veux pas faire ce genre de débat où l'on joue sur les mots, j'ai compris ce que tu voulais dire ;)
Je n'enlève rien à tous les propos du style ubuntu ne fait déjà pas de remonté etc. je veux juste égaliser un peu plus la balance en disant que à trop faire remarquer les défauts on peut passer à côté de quelquechose de bénéfique.
Mais bon, il semble que MS est tellement puissant que si cela arrive, cela ne servira qu'a lui donner tout les pouvoirs, et il va pouvoir forcer les développeurs à faire ce qu'il veut.
Je rappelle quand même ce qu'il dit :
"...convince me to change the date of the next Ubuntu LTS: the opportunity to collaborate"
(lire collaborate dans le sens collaborer)
if two out of three
(en parlant des distributions donc pas une hégémonie mondiale, juste deux)
puis il dit :
"Red Hat (RHEL), Novell (SLES) and Debian are willing to agree in advance [...] on a combination of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions"
Pas, on force les développeurs, mais on se met d'accord pour prendre des versions au pif, pas de tous les softs, mais des gros trucs gnome, X...
Ça coute rien d'essayer une fois, si il ne joue pas le jeu(alors que c'est le sien), c'est fini et puis voilà. Mais il est évident que ubuntu pourrait en tirer d'énormes profits étant donné tout ce que l'on lit sur la 8.04 et c'est peut-être ça qui gêne le plus ?
[^]Re: L'upstream
> mais on se met d'accord pour prendre des versions au pif, pas de tous les softs, mais des gros trucs gnome, X...
C'est absurde, GNOME a un cycle de développement de 6 mois et est parfaitement incapable de te dire ce qu'il feront dans 1 an et tu veux leur imposer un calendrier sur 2 ans ?
* cas 1: gros changement dans les 2 ans à venir.
Supposons que ta LTS sorte dans 2 ans, si GNOME décide de lancer GNOME 3 dans 18 mois, il fait quoi le père Shuttleworth ? Il dit: "hep hep, moi et mes copains -RH, Novell, Debian- on sort nos produits dans 6 mois, donc on bosse sur GNOME2, et GNOME 3 il attendra" ?
* Cas 2: je stoppe tout net.
J'ose même pas imaginer la réaction des kernels hackers, si tu leur annonce qu'ils doivent stopper tout gros changements dans le noyau parce que la version x.y.z pendant 6 mois à 1 an pour pouvoir tester/certifier ton noyau.
Idem pour GCC, Xorg, OOo qui ne se limite pas à la plateforme Linux.
Ce n'est pas possible parce que tu n'as pas un seul et unique maitre d'oeuvre, Apple ou Microsoft peuvent se le permettre car ils ont un contrôle total sur leur OS, dans le logiciel libre, c'est tout bonnement impossible.
La seule possibilité serait de remettre les clés à un individu ou pool d'individus, c'est ce qu'implique la proposition de Mark Shuttleworth.
*cas 3: je teste à mort la version
De plus ton cycle de développement de 2 ans, il passe à la trappe. Bien malin, celui qui en juin 2006 (début du cycle de la LTS actuelle) aurait prévu que gvfs (réalisé en moins de 6 mois) remplacerait Gnome-vfs, que PulseAudio allait finalement botter le cul d'ESD, que Linux aurait sa propre solution de virtualisation (KVM lancé fin 2006) etc ...
Même RedHat ou Novell, les deux plus grosses distributions sont incapable d'avoir une vision aussi précise sur le long terme. Au mieux, tu peux prévoir les orientations sur le long terme (virtualisation, bureaux composites, ..) mais guère plus.
Choisir une version au pif de GNOME pour la tester à mort est complètement stupide, c'est toute les versions de GNOME qui doivent être testé à mort. Idem pour les autres projets.
Il est inutile de se focaliser sur une seule version mais directement sur le travail en upstream.
> Mais il est évident que ubuntu pourrait en tirer d'énormes profits étant donné tout ce que l'on lit sur la 8.04 et c'est peut-être ça qui gêne le plus ?
Si Ubuntu est le seul à gagner, ça n'a aucun intérêt pour les autres surtout si c'est pour que les autres perdent. Le logiciel libre n'est pas au service d'Ubuntu que je sache.
[^]Re: L'upstream
> Ça coute rien d'essayer une fois
On peut voir les choses comme ça.
M'enfin, quel sont les rapports de force ?
Au pif :
RH : 10
Novell : 6
Ubuntu : 1
Ben n'empêche qu'Ubuntu veut fixer la date de release de RHEL, SLES ou Debian. Autour d'avril 2010 (plus ou moins 1 mois).
Que peut y gagner Red Hat ou Novell ?
Quasiment rien et en plus ils perdent en liberté.
RHEL est pour une boite commerciale où la date de release (comprendre les fonctionnalités ici) est critique pour le business. La date de release n'est pas importante dans son respect, mais dans la possibilité de la changée ! Pour ajouter telle ou telle fonctionnalité, pour passer de gcc 4.3 à gcc 5, etc.
Bref, fixer aujourd'hui pour Red Hat ou Novell la date de release où même les versions majeurs des principaux composant de leur "de dans 2 temps" distribution entreprise est quasi suicidaire.
L'excellent Russel Coker a fait un billet sur ça. Il n'est pas vraiment d'accord moi on va dire :
http://etbe.coker.com.au/2008/05/13/release-dates-for-debian(...)
Il propose que Debian se synchronise avec RHEL.
Mais, il y a une énorme différence avec Ubuntu. Il reconnait le rapport de force, il n'impose pas de calendrier à RHEL.
It seems to me that the best way of achieving the goal that Mark advocates (in the short term at least) is for Debian to follow Red Hat’s release cycle.
Il insiste plus sur les composants que sur la date de sortie. Debian sortira quand elle jugera qu'elle est prête.
M'enfin, je pense que ça passera plus par une collaboration avec Fedora que directement avec RHEL.
Biensûr que Red Hat / Fedora ne va pas refuser ce type de collaboration et que les choses seront fait pour que ça soit du gagnant-gagnant.
Mais ce que propose Ubuntu, et notamment pour des distributions entreprise (avec enjeux commercial), ce n'est pas du gagnant-gagnant.
C'est du gagnant pour Ubuntu et c'est tout.
Ubuntu a choisi de sortie des releases à date fixe. Ubuntu a ses raisons pour ça.
Les autres n'ont pas choisi ce modèle. Ils ont aussi leur raison. Mais Ubuntu veut imposer son modèles aux autres. Qui y gagne ? Que Ubuntu.
On peut chipoter sur le verbe "imposer". M'enfin, il a dit que la date de release c'est avril 2010 (plus ou moins un mois). J'image que pour Red Hat et Novell, voir ça est de la science fiction.