Il est peut-être intéressant de tenter une revue globale (avec les citations issues des sites web officiels) afin de d'analyser les diverses solutions adoptées et d'en présenter les forces et les faiblesses.
Regardons plus en détails les politiques de sortie de divers noyaux et systèmes (Linux, OpenBSD, FreeBSD, NetBSD), distributions GNU/Linux (Gentoo, Debian, Mandrake, Fedora, Slackware), gestionnaires de bureau et autres (GNOME, KDE, Mozilla).
Noyau et OS :
Noyau Linux => à la discrétion du "dictateur bienveillant" (Linus Torvalds).
OpenBSD => avec une périodicité fixe tous les 6 mois.
FreeBSD => quand la version current est suffisamment déboguée pour remplacer la branche stable.
NetBSD => quand la version current est suffisamment déboguée pour remplacer la branche release.
Distributions GNU/Linux :
Gentoo => avec une périodicité fixe tous les 3 mois.
Citation trouvée sur le site : February 2004 : 2004.0 ; April 2004 : 2004.1 ; July 2004 : 2004.2 ; October 2004 : 2004.3
Debian => sortie de "Stable" quand la branche "Testing" ne comporte plus de bugs critiques.
Citation trouvée sur le site : Aucun objectif précis n'a été fixé, et aucune date de sortie officielle ne sera fixée à l'avance.
Mandrake => sortie de la version "Official" quand la version "community" est suffisamment stabilisée.
Citation trouvée sur le site : Une branche stable de Mandrakelinux 10.0 sera alors ouverte, basée sur Mandrakelinux 10.0 Community.
Fedora => avec une périodicité "plus ou moins fixe" tous les 4 à 6 mois.
Citation trouvée sur le site : The project will produce time-based releases of Fedora Core about 2-3 times a year.
Slackware => à la discrétion du "dictateur bienveillant" (Patrick Volkerding)
Citation trouvée sur le site : It's usually our policy not to speculate on release dates, since that's what it is -- pure speculation.
Gestionnaires de bureau et autres :
GNOME => avec une périodicité fixe tous les 6 mois.
Citation trouvée sur le site : GNOME releases are defined by the GNOME Release Team and are scheduled to occur every six months.
KDE => avec une périodicité souhaitée tous les 5 mois (seulement indicative).
Citation trouvée sur le site : A major release takes approx. 5 (!!) months from the first announcement to the final release. A minor release takes approx. 2 months....The dates mentioned serve as an indication only.
Mozilla => avec une périodicité "plus ou moins fixe" tous les 3 mois.
Citation trouvée sur le site : The Mozilla project has been following a quarterly milestone plan that emphasizes regular delivery of stable new-feature releases.
Quand on tente d'y voir plus clair dans ce fouillis on constate que dans le domaine des OS le projet OpenBSD semble l'exception avec sa périodicité rigide. C'est sans doute le reflet de la cohésion qui règne entre les membres d'une équipe relativement réduite et de l'existence d'un responsable de projet charismatique (Theo de Raadt).
Ces deux facteurs réunis permettent la définition d'objectifs clairs à 6 mois et la tenue de la date limite.
Dans le cas du noyau Linux il existe également un responsable de projet incontesté (Linus Torvalds) mais le grand nombre de développeurs impliqués interdit toute planification trop contraignante.
C'est un modèle pyramidal qui est choisi avec plusieurs branches de développements dirigés par des individus précis (-mm pour Andrew Morton ; -ck pour Con Kolivas ; -aa pour Andrea Archangeli) et c'est Linus qui ensuite fait monter les patchs de ces branches dans la branche officielle (mainline).
Les autres projets BSD utilisent une politique plus classique avec une version stable et une version de développement.
Le basculement est décidé par l'équipe quand elle estime qu'un certain niveau de maturité est atteint.
Pour les distributions GNU/Linux le paysage est également très contrasté.
Les deux « pointures » commerciales que sont Suse et RedHat ne bénéficient pas d'une large communauté de contributeurs et la politique des sorties est définie en interne sans grande visibilité extérieure.
La Gentoo vient d'opter il y a quelques mois pour une périodicité fixe mais comme il s'agit d'une meta-distribution que l'on construit et que l'on synchronise soit même la notion de sortie perd beaucoup de son importance.
La distribution Debian est connue pour sortir une version stable uniquement "when it's done" et donc pour avoir un rythme de sortie plus lent que les autres.
Les utilisateurs de serveurs apprécient la stabilité et la pérennité de la version stable alors que les utilisateurs de postes de bureau semblent condamnés à la version de développement (Sid) pour avoir des logiciels à jour.
Récemment le responsable du projet de Debian a annoncé qu'une réflexion était engagée pour basculer vers une politique de périodicité fixe.
Mandrake, comme Gentoo, a récemment changé de système de sortie. La distribution française utilise maintenant une formule à double étage : une version "Community" qui est identique aux anciennes versions et une version "Official" qui est une Community + les correctifs des deux ou trois premiers mois de son existence.
Le rythme de sortie est assez élevé car la distribution cible surtout les utilisateurs en poste de bureau ce qui nécessite d'être très à jour dans les paquets.
La Fedora est une formule hybride originale : le but est de devenir la version « communautaire » de la RedHat et de servir ainsi de banc d'essai pour les nouveautés techniques avant l'intégration dans les versions RHEL.
Les sorties sont donc relativement fréquentes du fait de la vocation de "test" auprès de la communauté (actuellement il semble toutefois que la grande majorité du travail reste effectué par les développeurs RedHat).
La Slackware est une sorte d'exception dans le monde des distributions GNU/Linux en ce sens qu'il s'agit d'une distribution historique et très réputée mais qui est porté à bout de bras quasiment par un seul homme (Patrick Volkerding).
Cela n'est rendu possible que par le choix du minimalisme (dans la gestion des paquets ou dans la procédure d'installation) et par une politique de modification minimale des logiciels utilisés.
Enfin en ce qui concerne le monde des postes de bureau on constate que les projets Mozilla et KDE utilisent sensiblement le même schéma : les développeurs du projet se donnent collectivement une calendrier plus ou moins fixe (en fonction de l'importance estimée des modifications) pour chaque nouvelle sortie.
En outre Mozilla maintient pour les entreprises une branche "très stable" de sa suite pendant une longue période.
Le projet Gnome par contre est axé sur une périodicité fixe de 6 mois.
Ce schéma a été choisi après le mini-traumatisme qu'a constitué le passage difficile et tardif vers la version 2.0 du projet. Pour profiter à plein de cette nouvelle infrastructure et rattraper le retard c'est une cadence de sortie rigide qui a été préférée.
Il est à noter que pour un projet de cette sorte (grand nombre de développeurs + diversité fonctionnelle des logiciels + absence de responsable charismatique) ce choix peut sembler osé mais il semble bien fonctionner (toutefois il semble que des décalages de dates limites interviennent plus souvent que sur le projet OpenBSD qui est calé sur le même rythme).
# au sujet des distributions
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Se trouve le problème que malgré qu'on est une base stable (le kernel, X et les bureaux), il faille tout de même se taper des applications rapidement obsolètes car évoluant plus vite.
Pour moi, je considère qu'une distribution est stable quand seulement la base est stable, que tout les composants de bases fonctionne bien ensemble.
Pourquoi n'aurait-on pas par exemple dans Mandrake, la possiblité de mettre à jour les applications de "haut niveau" ? Pourquoi faudrait-il attendre 6 mois pour avoir une nouvelle version de la distribution afin d'avoir une mise à jour de la dernière version de Mozilla, Grisbi ou open-office etc . ? Serait-ce parce que les editeurs craignent que ça mette la stabilité du système en danger ? Ils ne font pas confiance aux équipes de développement qui produisent lesdits logiciels quand ils sortent une nouvelle version stable ? Ce n'est pas une raison suffisante pour les proposer en mise à jour ? Quelles autres raisons ? Je n'en vois pas.
En mettant à jour à la main ce genre d'application, je n'ai jamais rencontré de problème. L'appli XYZ en général n'en a strictement rien à foutre de la version du kernel ou de X ou de je ne sais quel autre logiciel de base. Par contre, c'est un problème pour l'utilisateur, parce que c'est chiant de mettre à jour à la main et qu'on ne peux pas profiter des facilités de Urpmi ou apt.
Je pense qu'une distribution devrait être coupée en deux : Il y aurait un repository des paquets des logiciels de base (kernel &co). Ce repository servirait de réference par rapport aux versions officielles de la distribution. Et un deuxième repository contenant les paquets des applications de plus haut niveau (les applis bureautiques, et autres), qui ne connait pas de versionning et dans lequel les applis seraient mis à jour régulièrement au fur et à mesure qu'elles sortent, que l'on pourrait donc mettre à jour sur son système avec apt ou urpmi ou équivalent sans avoir à attendre 6 mois ou plusieurs années avant d'en profiter.
Actuellement, si on veut utiliser les dernières versions des applis, il faut installer une cooker ou équivalente, dont la base est jugée instable (puisqu'en test et c'est normal). Bref, on a deux choix :
- Soit on se traine avec des vieilles applis obsolètes mais une base système stable. (donc on se traîne les éventuels bugs de ces vieilles applis pendant des mois)
- Soit on a les derniers versions des applis mais avec une base système instable.
Je trouve ça ridicule.
En tant qu'utilisateur, je veux pouvoir mettre à jour openoffice, mozilla, ou je ne sais qu'elle autre application "desktop" sans attendre 6 mois, sans avoir à tout reinstaller quand enfin une nouvelle version de la distrib sort, tout en profitant du système de mise à jour simple et efficace de ma distribution.
[^] # Re: au sujet des distributions
Posté par Antoine Reilles (site web personnel) . Évalué à 10.
C'est pour ça que certaines personnes installent une slackware minimale pour aboir la base, et greffent dessus pkgsrc (le système de ports de netbsd, conçu pour être assez portable) pour installer les softs au dessus de cette base.
C'est une solution sympatique, mais bien sûr, tu perds la guarantie de cohérence que te donnent la plupart des distributions linux. Sous debian stable, si quelque chose ne marche pas, c'est a coups sûr de ta faute : tu as mal configuré quelque chose, ou mal compris la doc, alors que là, et bien, c'est peut être un bug de la version courante, ou une incompatibilité avec une lib, et les possibilités de merdoiement sont infinies
[^] # Re: au sujet des distributions
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Je reessairais d'en installer une à l'occasion alors :-)
[^] # Re: au sujet des distributions
Posté par MsK` . Évalué à 1.
[^] # Re: au sujet des distributions
Posté par Cedric Malherbe (site web personnel) . Évalué à 6.
http://platform.progeny.com/componentized/about.html(...)
[^] # Re: au sujet des distributions
Posté par cedricv . Évalué à -2.
c'est pour ça que certaines personnes plus "fut-fut" installent une gentoo et utilisent emerge (qui a le meme principe que les vénérable ports de bsd, mais encore plus avancé)
[^] # Re: au sujet des distributions
Posté par gallenza . Évalué à 5.
[^] # Re: au sujet des distributions
Posté par Temsa (site web personnel) . Évalué à 2.
Je peux te dire que c'est pas si contraignant par rapport à ce que ça apporte!
PS: J'en suis à 6 gentoo installées sur différents poste, et c'est devenu de loin ma distrib préférée, même si je laisse une chance aux autre ;)
[^] # Re: au sujet des distributions
Posté par Yusei (Mastodon) . Évalué à 9.
Je pense que tu n'as pas compris le sens de la dénomination "stable" et "unstable" de Debian. Cette dénomination ne fait pas référence à la stabilité des logiciels, mais de leur packaging. Un logiciel peut être plein de bugs et néanmoins être inclus dans stable du moment que son paquet respecte les conditions nécessaires.
Utiliser une Debian stable ne te donne pas de garantie que ton système ne plantera pas, cela te donne une garantie (relative) que rien ne sera cassé lors d'une mise à jour, que les dépendances entre les paquets sont correctes, etc.
[^] # Re: au sujet des distributions
Posté par Gilles Mocellin . Évalué à 3.
Il y a donc deux solutions pour qu'un package passe :
- il est stable
- il n'a pas été testé ! ou en tout cas, pas assez.
[^] # Re: au sujet des distributions
Posté par Gilles Mocellin . Évalué à 4.
Et là, ça implique le noyau et X au moins... Pas très périphériques comme applications.
Pour Mandrake, je pensais que la comunity serait comme tu le dis, avec les applications bureautiques mises souvent à jour, mais c'est pas vraiment ça.
Par contre, les membres du club ont des packages récents mis à dispo.
Sinon, moins à la portée du premier venu, on peut aussi backporter des packages des versions de dev (recompiler les SRPMS de cooker pour Mandrake par ex).
Chez Debian, il y a des backports aussi (http://www.backports.org/(...)) et tout un tas de gens qui mettent à dispo des package (http://www.apt-get.org/(...))
En conclusion, je crois que le cas n'est pas simple.
PS:
Il y a peut-être une place à prendre pour une nouvelle distrib.
[^] # Re: au sujet des distributions
Posté par Ph Husson (site web personnel) . Évalué à 0.
L'inconvenient (majeur) c'est que c'est à partir de sources
Notament avec gentoo
La distribution qu'on develope à trois a aussi trois branche (devel testing et stable) (Accessoirement on essaye de gérer des binaires en même temps ca marche pas trop trop mal mais c'est pas trop ça quand même)
Et des distributions comme ça il doit y en avoir un certains nombre
Bref ça existe mais c'est pas pratique à utiliser (en général quand on veut ce genre de choses c'est pour un serveur et bon compiler sur un serveur c'est pas top)
[^] # Re: au sujet des distributions
Posté par tgl . Évalué à 2.
> pour un serveur et bon compiler sur un serveur c'est
> pas top)
Attention, ne pas croire qu'il y a besoin de compiler sur toutes les machines Gentoo. Y'a les paquets binaires officiels, les paquets binaires qu'on se fait à sa sauce sur d'autres machines plus adaptées du réseau, etc. Des serveurs Gentoo sans même un gcc installé, c'est parfaitement possible et courant.
[^] # Re: au sujet des distributions
Posté par Jllc . Évalué à 3.
Pour le noyau, un changement de version ne devrait pas pertuber les applications, car les interfaces (système de fichier, accès au périphériques) sont à ma connaissance stables, et je n'ai d'ailleurs pas rencontré de problème en pratique. Reste les programmes gérant directement des modules noyau (iptables, ppp ..), mais il doivent être assez rares pour que ce soit gérable.
Pour X, on a justement un fonctionnement client/serveur, avec un protocol bien standard entre les deux. On devrait normalement pouvoir gérer séparement le serveur (avec les pilotes mis à jour) et les Xlibs coté clients.
Je pense en plus qu'avoir des "bases" stable facilerait le déploiement de Linux en entreprise, car une "configuration" donnée serait pereine quelques années, et les vendeurs/distributeurs d'applications pourrait fournir leurs programmes en était assuré de trouver cette base chez leur client.
L'idéal serait même d'avoir des "configurations de base" communes à plusieurs distributions. Les utilisateurs aurait le choix de la distrib, et les développeurs serait assurés de fournir un truc compatible.
[^] # Re: au sujet des distributions
Posté par chl (site web personnel) . Évalué à 5.
Une solution possible pour realiser ce que tu dis, c'est d'utiliser le fichier /etc/urpmi/skip.list
$ cat /etc/urpmi/skip.list
# Here you can specify the packages that won't be upgraded automatically
Et tu te fais 2 scripts, qui mettent dans ce fichier soit :
1/ La liste des packages de bases
2/ Le reste des packages
Ensuite tu passes en cooker, en commencant par mettre la premiere liste de packages (pour pas qu'ils soient mis a jour), et tu lances urpmi comme avant ...
J'avous que c'est crade, mais je pense que ca repond a ton besoin :)
J'imagine que le meme principe est faisable sous Debian ...
[^] # Re: au sujet des distributions
Posté par 007 . Évalué à 2.
Peut-être par manque de temps/argent ?
Faut faire le paquet, compiler, tester un minimum (problème de compatibilité), mettre sur les mirroirs, etc...
A celà s'ajoute tous les problèmes de dépendance... (les logiciels évoluent et leurs dépendances aussi), le problème d'audit du code, etc...
Bref, la complexité augmente en flèche.
Pour Fedora, il faut un mois de freeze complet (pas de changement de version et que des corrections de bugs) pour fiabiliser alors que les développeurs ne s'occupent que de ça. Pourtant il reste encore des problèmes lors de la release finale...
Monter en version un paquet se fait parfois sans accro. Ce n'est pas toujours le cas.
# Et E17 ?
Posté par Wawet76 . Évalué à 2.
Dans un article sur les différentes façon de planifier des sorties, ça manque :)
[^] # Re: Et E17 ?
Posté par N-Mi . Évalué à 2.
AMHA je crois qu'il est beaucoup trop tôt pour le projet E17 de choisir une choisir une date de sortie (même très approximative), et je ne pense pas que Rasterman me contredira sur ce point. L'avancement des bibliothèques de base (EFL) est correct et régulier (à en juger par l'activité du CVS). On peut espérer que d'ici quelques temps ces bibliothèques seront jugées assez matures pour pouvoir commencer à attaquer le gestionnaire de fenêtre lui même, ce qui risque d'aller assez vite, compte tenu que le terrain aura bien été débroussaillé avant.
Alors évidemment, on ne peut pas commencer à espérer une sortie de E17, mais certaines bibliothèques sont déjà en état de fonctionnement et peuvent être utilisées par les développeurs (il y a déjà quelques applis en développement qui utilisent ces bibliothèques).
[/mode]
# Gentoo
Posté par kerokero . Évalué à 2.
En gros il y aurait donc une release dès qu'un soft est mis à jour.
Quelqu'un aurait il plus de precisions à ce sujet ?
[^] # Re: Gentoo
Posté par Stephen Amar . Évalué à 2.
donc gentoo est en perpetuelle évolution, c'est une metadistribution, il n'y a pas un kernel, il y a une vingtaine de version différente, (vanilla, gentoo, mm, aa, ck, gaming, gentoo-dev, devel etc....)
il y a 2 serveurs X au choix (X11, Xorg)
etc...
[^] # Re: Gentoo
Posté par tgl . Évalué à 2.
Oui, une "release" Gentoo, c'est juste une collection de :
- Live CD (pour l'install, le dépannage, ou bien encore juste pour utiliser comme n'importe quelle knoppix ou assimilé)
- images systèmes initiales pour l'install (les "stages", qui comprennent les outils et commandes de bases)
- une collection de paquets précompilés des paquets stables du moment
Mais effectivement rien n'est figé entre deux releases, de nouveau paquets/versions sont marqués stables, etc.
Côté utilisateur, les modes d'utilisation varient énormement, et un bidouilleur sur sa machine perso ne va pas avoir du tout la même politique de mise à jour qu'un admin sur un serveur. Là où par exemple l'un va se compiler régulièrement toutes les mises à jours possibles (éventuellement même avec des paquets en test), l'autre se contenter des mises à jour de sécurité de façon régulière, et ne faire que de temps en temps (genre une fois par an) des mises à jour de fonctionnalitéd en se basant sur les binaires précompilés.
Bref y'en a pour tout les goût, et c'est aux utilisateurs de choisir ce qu'ils veulent freezer ou non.
# Hummm
Posté par 007 . Évalué à 4.
- les objectifs
RHEL ne va pas sortir tout les 6 mois car l'objectif est d'avoir un système perenne (5 ans). Si il y a une nouvelle version tout les 6 mois, celà fait jusqu'à 10 versions à maintenir en même temps !
Fedora dont la perennité est courte peut sortir plus souvent. Parlé de la fréquence de sortie sans prendre en compte les objectifs n'est pas "très sérieux".
Puis les distributions c'est particulier. C'est pas vraiment lié à son développement mais au développement de tous les autres. Si la distribution ne bouge pratiquement pas mais qu'il y a une nouvelle version de Gnome ou KDE, alors il y aura une nouvelle version de la distribution.
> Les deux « pointures » commerciales que sont Suse et RedHat ne bénéficient pas d'une large communauté de contributeurs
> actuellement il semble toutefois que la grande majorité du travail reste effectué par les développeurs RedHat
Mouaifffff
Ce n'est pas tout à fait faux.
Mais ce n'est pas tout à fait vrai.
Je ne parle pas de SuSE que je connais peu.
Prenons Fedora. Pour la prochaine FC3, udev n'était pas vraiment prévu car il y avait des problèmes génants selon Red Hat (côté mkinitrd notament). Des développeurs d'udev sont passés sur la mailing devel de Fedora pour fixer les problèmes et il est maintenant plus que probable que udev sera par défaut dans FC3.
FC2 poussait SeLinux, et quelques développeurs de SeLinux ont aussi participés à FC2.
Fedora n'est pas communautaire (comme Debian) et moins ouverte que Mandrake par exemple (ça devrait changer avec un nouvelle système de build qui ... sait se faire désiré :-)).
Mais les développeurs de Red Hat sont si impliqués en upstream qu'il y a forcément une grosse communauté derrière mais si c'est "à distance".
L'un des objectifs de Fedora est d'être synchro avec l'upstream :
http://fedora.redhat.com/about/objectives.html(...)
Do as much of the development work as possible directly in the upstream packages.
Ainsi des gros projets comme le noyau, gcc, binutils, gnome etc peuvent sortir avec la dernière version disponible et très peu de patch grace à la participation en uptream (et à distance par rapport à la distribution).
Mon argumentaire n'est pas très brillant, mais Fedora a une grosse communauté. Pas forcément très nombreuse ou qui intervient directement. Mais techniquement de haute volée.
Il serait bien d'avoir un sondage sur les distributions utilisées par les développeurs en upstream. Je ne serais vraiment pas étonné que Fedora soit en tête même si les développeurs ne participent pas directement au développement de la distribution.
Ceci dit, il y a aussi fedora.us pour les contributions externes :
http://www.fedora.us/(...)
Et pour mettre un bénol à tout ça, les outils de configuration, les scripts de boot, l'installeur, etc (ce qui est vraiment du domaine de la distribution) reste à 90 % dans les mains d'employés Red Hat.
Donc je te donne raison pour la partie distribution. Mais une distribution comme Fedora n'a pas comme objectif d'uniquement paufiner les outils de configuration, l'installateur, etc... Ç'est 5 à 10 % du boulot de Red Hat/Fedora alors que leur métier est de faire une distribution.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.