Et le problème, c'est que ça ne peut pas marcher !
Exemple (oui, avec RH et Fedora).
RHL (qui a donné Fedora) et Fedora ont des dates de sorti régulières (tous les 6 mois en gros).
- RH 8.0 : devait avoir ACL => Désactivé à la sorti.
- FC2 : devait avoir SeLinux activé par défaut => Désactivé à la sorti.
- F8 : ne devait plus avoir Xen => Ben il reste un peu de Xen.
On peut multiplier les exemples. Dans le wiki de Fedora, il y a les features approuvées. Ben c'est rare qu'elles restent toutes jusqu'à la sortie de la version finale.
On voit bien qui y a un besoin de découpler un peu l'upstream des distributions. Si les deux peuvent travailler ensemble et sur un même planning, tant mieux. Mais ce n'est pas toujours le cas.
Mark Shuttleworth dépeint un tableau idéal, où les développements upstream sont terminés à l'heure dite. Le "problème", est que des projets seront en avance et tu ne pourras pas les empêcher de bosser de suite sur d'autres nouveautés. Nouveauté qui seront trop en avant pour l'Ubuntu suivante, et pour la suivant Ubuntu va passer de la version n à n+2 (qui va être livré en "retard"). C'est comme ça. Red Hat ou n'importe qui n'a aucune autorité dans ce domaine. Le libre est et reste libre (et aussi dans son planning).
La "feature" de la prochaine Ubuntu LTS est sa date de sortie. Très bien, c'est le choix d'Ubuntu.
La "feature" de la prochaine RHEL sera probablement ext4. Et ext4 quand ça sera prêt pour les entreprises. À quelle date ? Ben on ne sait pas.
Les entreprises ne veulent pas une date de sortie, elles veulent des fonctionnalités. Elles ne veulent pas du "demain au jour j je rase gratis", elle veulent savoir si ça rase de prêt aujourd'hui.
Les distributions entreprises comme RHEL ou Novell ne sortent quasiment jamais avec la dernière version upstream.
Pourquoi ?
Car assez souvent ce que demande leurs clients n'est pas accèpté upstream.
Par exemple RHEL 3 est sorti avec un noyau 2.4 et nptl. nptl a été refusé pour Linux 2.4 pour certainement de très bonnes raisons.
Red Hat fournit depuis très très longtemps GFS. GFS a mis des plombes avant d'être upstream. La maturation de GFS dans RHEL a aussi permis son entré en upstream. Donc encore, il faut parfois un découplage entre les distributions (et notamment celles pour les entreprises) et l'upstream. En général pour RHEL, Red Hat prend un noyau upstream et bosse 6 mois dessus (car le partenaire machin à demandé bidule qui n'est pas upstream, car Red Hat fait du "tuning" (efficace mais ugly (et donc non upstream), etc).
Mais alors pourquoi Fedora, Mandriva, Ubuntu etc sortent à date régulière ?
Car ces dernières ont une communauté de développeurs. Si tu freezes trop longues la distribution, les contributeurs vont voir ailleurs.
Si Red Hat freeze Fedora durant 6 mois car Red Hat veut avoir un GFS2 top moumoute avec des benchs qui feront joli dans un communiqué de presse, ou car Red Hat paufine la doc ou attend la certification d'Oracle, etc ben les contributeurs vont fuire Fedora.
Une entreprise ne va pas déployer X ou Y car c'est sorti à la date prévu. Mais car elle y voit un bénéfice.
Vista serait sorti à la date prévu, ça n'aurait rien changé. Les entreprises ont globalement boudé Vista.
Le développement dans le libre est continu. Il ne peut pas être cadencé. C'est mal. Mais un mal nécessaire.
[^] # Re: moui
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet ça. Évalué à 6.
Exemple (oui, avec RH et Fedora).
RHL (qui a donné Fedora) et Fedora ont des dates de sorti régulières (tous les 6 mois en gros).
- RH 8.0 : devait avoir ACL => Désactivé à la sorti.
- FC2 : devait avoir SeLinux activé par défaut => Désactivé à la sorti.
- F8 : ne devait plus avoir Xen => Ben il reste un peu de Xen.
On peut multiplier les exemples. Dans le wiki de Fedora, il y a les features approuvées. Ben c'est rare qu'elles restent toutes jusqu'à la sortie de la version finale.
On voit bien qui y a un besoin de découpler un peu l'upstream des distributions. Si les deux peuvent travailler ensemble et sur un même planning, tant mieux. Mais ce n'est pas toujours le cas.
Mark Shuttleworth dépeint un tableau idéal, où les développements upstream sont terminés à l'heure dite. Le "problème", est que des projets seront en avance et tu ne pourras pas les empêcher de bosser de suite sur d'autres nouveautés. Nouveauté qui seront trop en avant pour l'Ubuntu suivante, et pour la suivant Ubuntu va passer de la version n à n+2 (qui va être livré en "retard"). C'est comme ça. Red Hat ou n'importe qui n'a aucune autorité dans ce domaine. Le libre est et reste libre (et aussi dans son planning).
La "feature" de la prochaine Ubuntu LTS est sa date de sortie. Très bien, c'est le choix d'Ubuntu.
La "feature" de la prochaine RHEL sera probablement ext4. Et ext4 quand ça sera prêt pour les entreprises. À quelle date ? Ben on ne sait pas.
Les entreprises ne veulent pas une date de sortie, elles veulent des fonctionnalités. Elles ne veulent pas du "demain au jour j je rase gratis", elle veulent savoir si ça rase de prêt aujourd'hui.
Les distributions entreprises comme RHEL ou Novell ne sortent quasiment jamais avec la dernière version upstream.
Pourquoi ?
Car assez souvent ce que demande leurs clients n'est pas accèpté upstream.
Par exemple RHEL 3 est sorti avec un noyau 2.4 et nptl. nptl a été refusé pour Linux 2.4 pour certainement de très bonnes raisons.
Red Hat fournit depuis très très longtemps GFS. GFS a mis des plombes avant d'être upstream. La maturation de GFS dans RHEL a aussi permis son entré en upstream. Donc encore, il faut parfois un découplage entre les distributions (et notamment celles pour les entreprises) et l'upstream. En général pour RHEL, Red Hat prend un noyau upstream et bosse 6 mois dessus (car le partenaire machin à demandé bidule qui n'est pas upstream, car Red Hat fait du "tuning" (efficace mais ugly (et donc non upstream), etc).
Mais alors pourquoi Fedora, Mandriva, Ubuntu etc sortent à date régulière ?
Car ces dernières ont une communauté de développeurs. Si tu freezes trop longues la distribution, les contributeurs vont voir ailleurs.
Si Red Hat freeze Fedora durant 6 mois car Red Hat veut avoir un GFS2 top moumoute avec des benchs qui feront joli dans un communiqué de presse, ou car Red Hat paufine la doc ou attend la certification d'Oracle, etc ben les contributeurs vont fuire Fedora.
Une entreprise ne va pas déployer X ou Y car c'est sorti à la date prévu. Mais car elle y voit un bénéfice.
Vista serait sorti à la date prévu, ça n'aurait rien changé. Les entreprises ont globalement boudé Vista.
Le développement dans le libre est continu. Il ne peut pas être cadencé. C'est mal. Mais un mal nécessaire.