vendredi 10 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Les politiques de sorties des grands projets Open Source

Posté par patrick_g (page perso, ). Modéré le 23 juillet 2004.
0
Le rythme d'apparition (« releases ») des grands projets libres est extrêmement variable et ne semble pas obéir à un schéma commun identifiable.
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).

> Lire la suite (22 commentaires, moyenne: 3,8).   [dépêche : 7119 caractères]


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).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

au sujet des distributions

Posté par Laurent J (page perso, ) le 23/07/2004 à 20:15. (lien). Évalué à 17.

Pour moi, aucune des politiques de releases des distributions ne me satisfait. Je ne comprend pas pourquoi pour debian par exemple, il faudrait qu'on attende que tout les logiciels inclus dans la distribution soient "stable". En quoi le logiciel trucmuche pour faire mes comptes influencerait sur le fonctionnement du kernel au point de devoir tester des mois la distrib avec telles versions de logiciels pour en sortir une version stable ?

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.

Et E17 ?

Posté par Wawet76 (page perso, ) le 23/07/2004 à 22:55. (lien). Évalué à 2.

Tu as oublier de parler du futur Enligthenment.
Dans un article sur les différentes façon de planifier des sorties, ça manque :)

Gentoo

Posté par kerokero (page perso, ) le 24/07/2004 à 07:17. (lien). Évalué à 2.

J'avais cru comprendre qu'en realite il n'y avait plus de release proprement dite, que les versions trimestrielles avaient pour seul but de fournir des images iso permettant une premiere installation pour pouvoir immediatement faire une mise à jour par Internet.

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 ?

Hummm

Posté par 007 () le 24/07/2004 à 11:38. (lien). Évalué à 4.

L'article (et pas la news cette fois) est intéressant mais il loupe un gros truc :
- 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.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1808s (dont 0.0751 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !