Ce changement implique que les nouvelles versions de Debian GNU/Linux devraient sortir tous les deux ans à partir du printemps 2010. Ce changement de stratégie ne garantit pas pour autant une date de sortie fixe. Dans le fonctionnement de Debian, un nouveau paquet entre dans « unstable », toujours nommée Sid, afin d'y être testé. La paquet, après avoir été suffisamment testé, migre vers « testing », actuellement nommée Squeeze, et continue d'être testé. Lorsque le gel (freeze) survient, aucun paquet ne peut migrer de « unstable » à « testing » et les développeurs sont encouragés à se concentrer sur la correction des bogues dit « release-critical », c'est à dire bloquant la transformation d'une « testing » en « stable ». C'est uniquement lorsque tous les paquets sont viables pour la stable que la « testing » devient une nouvelle « stable ».
Jusqu'à présent la « release team » décidait, suivant la liste des corrections en attente et des objectifs de la nouvelle version, de geler ou pas la version « testing ». Dorénavant le gel de la « testing » se produira au mois de décembre des années impaires (ceci dès décembre 2009, la première fois faisant exception à la règle car la précédente stable est sortie le 14 février 2009).
D'après l'annonce, le projet Debian prévoit les nouvelles versions plus précisément et permet aux développeurs du projet de mieux s'organiser sur le long terme. Du côté des utilisateurs, il devient possible de planifier les mises à jour du système plus facilement.
Il est a noter que le prochain gel va donc être au mois de décembre cette année, ce qui nous laisse prévoir la sortie de Squeeze au printemps 2010, soit environ une année après la sortie de Lenny. Il s'agit là d'une exception afin de permettre de s'adapter à ce changement.
Aller plus loin
- Annonce du changement de stratégie (6 clics)
- La vie d'un paquet (8 clics)
- Décision de freeze ou non (6 clics)
- DebConf9 (1 clic)
- Debian sur DMOZ (2 clics)
# la fin de Debian ?
Posté par Anonyme . Évalué à -9.
Ok, le cycle de release reste encore assez long, mais je suis quasiment sûr qu'il sera tôt ou tard raccourci.
Tout ça pourquoi ? pour avoir un environement desktop plus sexy, alors que ce qui fait la force de Debian est son environnement serveur et sa qualité professionnelle.
Maintenant, au boulot, j'aurais du mal à vendre du Debian plutôt que du Ubuntu par exemple.
D'ailleurs, je me demande si cela ne va pas être le coup de grâce face à la concurrence.
Les développeurs Debian sont des gens très brillants dans leur domaine, mais à mon sens incapable de s'organiser correctement et de prendre du recul pour avoir une quelconque vision cohérente à long terme.
Ceci a été illustré bien des fois, et en tant que fan de cette distribution, j'ai de la peine à retenir ma déception.
[^] # Re: la fin de Debian ?
Posté par mornik . Évalué à 10.
Le fait de geler la distrib au mois de décembre d'une année impaire, permet à tout le monde de connaitre, de manière fiable, la liste des nouvelles fonctionnalités, pas de la sortie de la prochaine stable.
A mon avis, l'auteur de la dépêche s'emballe un peu (désolé). Le fait de voir la distrib gelée en décembre d'une année impaire, ne signifie pas que la version stable sorte au printemps qui suit. Si les responsables qualité de debian reste scrupuleux, la prochaine stable peut tres bien sortir au mois de décembre suivant, si nécessaire.
Donc au contriare, je pense que c'est une bonne chose. On sait à l'avance et de manière fiable, ce que proposera la prochaine debian. Mais on ne sait pas quand elle sortira, mais comment : stable et prête.
Longue vie à Debian !!
Ps : Debian conserve aussi pour elle de nombreux avantages (porte ouverte aux trolls de tout poils) face à bubuntu.
[^] # Re: la fin de Debian ?
Posté par Anonyme . Évalué à -4.
Le gel de la distribution n'est en rien un gage de qualité.
C'est la version des logiciels intégrés et ensuite le processus de correction des bugs qui font la qualité d'une distribution.
Concernant le premier point, une date de sortie fixe n'est donc pas anodin, surtout pour une utilisation professionnelle (parce qu'il n'y a pas de synchronisation, c'est normal, entre les développeurs upstream et la distribution).
Quant au deuixième point, j'attends de voir ça. Je doute qu'un cycle de correction dure 1 an après le gel de la distribution.
Dans la pratique, aucune des autres distributions ne fonctionne comme ça, d'où quand même des soucis assez fréquents.
Dommage, encore une fois, que Debian perde sa spécificité.
PS : tu peux être en désaccord avec moi sans me moinsser, car après tout il n'y aucun dérrapage dans mes propos...
[^] # Re: la fin de Debian ?
Posté par Carl Chenet (site web personnel) . Évalué à 8.
Les développeurs Debian font la Debian et elle s'est toujours avérée être une distribution exemplaire. Alors tes considérations sur ces développeurs et leur soi-disante incapacité à prévoir quoique ce soit sur le long terme me paraît être un dérapage.
[^] # Re: la fin de Debian ?
Posté par Anonyme . Évalué à -3.
Alors par quel miracle Ubuntu a trouvé sa place sur le desktop en pompant 99% des paquets ?
Par quel miracle une version a pu mettre 24 mois pour sortir ?
Et l'énorme bug de sécurité SSH ?
La difficulté à trouver des consensus avec notamment l'impuissance du président élu ?
Le retard sur un bon paquet de choses dans le domaine de la sécurité ?
La quasi absence de marketing ?
Une excellente distribution, que j'utilise tous les jours, oui, mais pas irréprochable.
[^] # Re: la fin de Debian ?
Posté par Carl Chenet (site web personnel) . Évalué à 10.
Exemplaire car Debian gère un nombre impressionnant de plateformes et gère un nombre également impressionnant de logiciels disponibles empaquetés dans la distribution.
Debian c'est plus d'un millier de développeurs volontaires, bénévoles qui donnent du temps et leurs compétences à une œuvre commune qu'aucune entreprise privée n'aurait pu réaliser et qui permet au business du libre d'évoluer en permettant à des sociétés comme Canonical d'exister.
Je crois que tu méconnais beaucoup d'aspects du projet Debian et que tes attentes face à cette organisation de bénévoles ne sont pas appropriées.
[^] # Re: la fin de Debian ?
Posté par Anonyme . Évalué à 2.
Et puis surtout pas à moi, qui en fait largement la promotion et y contribue également autant que possible.
Aimer n'empêche pas de garder un peu d'esprit critique.
[^] # Re: la fin de Debian ?
Posté par barmic . Évalué à 7.
Au contraire je pense que sortire des version un peu plus régulièrement avec donc moins de changement entre les versions, va simplifier les upgrade.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: la fin de Debian ?
Posté par mornik . Évalué à 7.
Quand tu dits :
aucune des autres distributions ne fonctionne comme ça, d'où quand même des soucis assez fréquents.
Dommage, encore une fois, que Debian perde sa spécificité.
Peut-être justement que Debian se dote d'une spécificité supplémentaire. A savoir : on connaitra, longtemps à l'avance la liste des changement majeurs entre 2 versions stables. Pratique pour celui qui veux préparer sa migration (étude d'impact sur les évolution de php oou perl, par exemple) ou savoir s'il faut attendre la prochaine debian pour avoir telle ou telle version de logiciel ou s'il faut préparer un backport voir même changer de distribution pour un serveur spécifique.
Je crois au contraire que cette politique peut être payante sur le long terme, si bien sur il reste sur la maxime : release quand c'est prêt.
[^] # Re: la fin de Debian ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 10.
Non je ne m'emballe pas, c'est ce qui a été observé (pour la 4.0 et la 5.0) et c'est pour ça que décembre a été choisi pour le mois de gel. C'est ce qui est indiqué dans l'annonce faite par le projet, je n'ai pas sorti "printemps" de ma poche.
C'est à la fin du premier paragraphe de l'annonce.
The project chose December as a suitable freeze date since spring releases proved successful for the releases of Debian GNU/Linux 4.0 (codenamed "Etch") and Debian GNU/Linux 5.0 ("Lenny").
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: la fin de Debian ?
Posté par mornik . Évalué à 1.
[mode mauvaise fois on] de toute façon ils n'ont pas peur de repousser les dates impossible à tenir, donc ça revient au même :°[/mode mauvaise fois off]
[^] # Re: la fin de Debian ?
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Moi, avec un gel en décembre, on aura un sortie au mieux pour l'été. Sauf si la LTS d'unbuntu est calé sur le même rythme alors on aura convergence des efforts. Tant mieux.
L'objectif n'est pas non plus la dispersion et s'il y a convergence, c'est mieux pour tous. Plus il y a de remonté d'unbuntu dans debian, mieux c'est. Cela veut dire que le courant passe et que l'organisation sociale marche. Dans le cas contraire, on dirait qu'ubuntu pompe sans rien donner en échange...
Ubuntu a ses propres problématiques, debian a les siennes, notamment le grand nombre d'architecture. Chacun fait avancer l'autre.
[^] # Re: la fin de Debian ?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 9.
C'est la période de gel qui est fixée, pas la sortie. Le concept reste le même, temps que la distribution n'est pas prête, elle n'est pas libérée.
En fait on donne une date limite pour inclure des nouvelles fonctionnalités, une fois cette date passée, on stabilise le tout jusqu'à ce que ce soit stable.
Je penses qu'il s'agit d'un excellent changement de stratégie, il n'impacte pas le concept "when it's ready" et permet une meilleure planification pour tout le monde.
Ceci a été illustré bien des fois, et en tant que fan de cette distribution, j'ai de la peine à retenir ma déception.
Ça a été ma première réaction, mais en regardant de plus près, je suis très satisfait de ce changement, on garde le "when it's ready" mais on permet une meilleure planification (la période de gel peut d'étendre dix ans si les objectifs sont pas atteints). Deux ans pour ajouter des nouvelles fonctionnalités, après quand c'est prêt on envoie !
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: la fin de Debian ?
Posté par brunus (site web personnel) . Évalué à 6.
"L’idée c’est qu’en freezant à des dates proches, ce seront les mêmes versions amont des principaux logiciels qui seront employés dans les deux distributions. Cela devrait encourager les projets amont à apporter un soin particulier sur la version qui sera si largement utilisée."
Extrait des commentaires du blog Lis les commentaires du blog : http://www.ouaza.com/wp/2009/07/28/squeeze-freeze-en-decembr(...)
Perso ça me semble au contraire assez encourageant et cela consolide l'image de stabilité de la Debian.
[^] # Re: la fin de Debian ?
Posté par Carl Chenet (site web personnel) . Évalué à 4.
Cela permet au moins d'avoir une échéance claire. Après le freeze on peut présumer d'une date de sortie, mais qui sera forcément repoussée si la qualité n'est pas au rendez-vous, selon la pratique en cours chez Debian.
De toute façon c'est une tentative comme le fait remarquer Raphaël Hertzog , développeur Debian sur son blog [http://www.ouaza.com/wp/2009/07/28/squeeze-freeze-en-decembr(...)]. Il faudra voir ce que ça donne en pratique.
# Ah?
Posté par Alexis . Évalué à -3.
[^] # Re: Ah?
Posté par Etienne Bagnoud (site web personnel) . Évalué à 6.
Le freeze c'est lorsque plus aucun paquet ne peut passer dans la testing. On arrête la migration de unstable -> testing. Durant le temps de freeze, une liste de bugs "release-critical" est émise et quand tous ces bugs sont corrigés, la testing devient la nouvelle stable, la stable devient la oldstable et la unstable devient la testing.
Donc le freeze se faisait quand c'était jugé utile, maintenant on c'est quand ça commence.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Ah?
Posté par Vincent Meurisse (site web personnel) . Évalué à 10.
Petite correction : la unstable ne devient pas la testing. La unstable reste unstable. Les paquets recommencent juste à passer automatiquement de unstable à testing.
[^] # Re: Ah?
Posté par Spyhawk . Évalué à 4.
(désolé, mal aux yeux, toussa... j'suis de loin pas un spécimen irréprochable, mais là.. )
[^] # Re: Ah?
Posté par thedude . Évalué à 1.
[^] # Re: Ah?
Posté par huitopy . Évalué à 3.
Mais après, c'est souvent une histoire de dépendances qui bloque le passage des paquets en testing après le délai de 10 jours.
Je crois que certains bogues signalés peuvent aussi bloquer le passage de l'un à l'autre mais là je ne suis pas sûr.
[^] # Re: Ah?
Posté par Adrien . Évalué à 4.
– plus de 10 jours en unstable ;
– pas de bugs bloquant ;
– que les dépendances ne posent pas de problème (si toto dépend de libmichu-2.4, alors il faut d'abord que libmichu-2.4 passe en testing).
Pour les mise à jour de sécurité c'est plus rapide il me semble.
[^] # Re: Ah?
Posté par Yannick . Évalué à 3.
L'idéal serait de geler Testing, de n'y accepter que les corrections de bogues et de continuer à alimenter Unstable. Le problème, c'est que ça obligerait les mainteneurs des paquets à s'occuper des deux versions : celle gelée dans Testing et la "roling-release" dans Unstable.
[^] # Re: Ah?
Posté par Dr BG . Évalué à 2.
# Une pression supplémentaire pour les développeurs
Posté par Guy . Évalué à 5.
Cela signifie que l'on aura en moyenne une version tous les 2 ans (ce qui est la moyenne actuelle). Pour ma part, je trouve que c'est beaucoup : les old-stable ne sont pas maintenus très longtemps. J'en connais qui traînent encore des potato et des sarge ...
Guy
[^] # Re: Une pression supplémentaire pour les développeurs
Posté par nodens . Évalué à 7.
Pour les serveurs (ou même les stations de travail) ça serait le pied. Le choix des paquets pourrait se faire à l'avance (le popularity contest ou les mainteneurs qui inscrivent leur paquet dans la liste par exemple), avec une équipe moins fermée que security (comme l'équipe qui s'occupe de la sécurité de testing).
Steve Langasek évoquait quelque chose comme ça il y a un an ou deux il me semble.
En ce qui me concerne, j'ai quelques réticences à basculer sur Ubuntu pour les serveurs, mais la LTS me fait de l'oeil depuis un moment, avec le cycle de support de Debian qui se raccourcit de fait. Ce qui m'embête c'est que la LTS ne sort pas quand elle est prête, mais quand sa date de sortie arrive...
Je proposerai bien cette idée sur debian-project mais j'ai un peu peur de déclencher une flamewar, on va la tester un peu ici d'abord ;-)
[^] # Re: Une pression supplémentaire pour les développeurs
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Donc, une mise à jour de sécurité réduite, je suis sur que cela marche.
Dans le même ordre d'idée, avoir quelques logiciels typé bureau qui évoluerait, ce serait aussi pas mal... Si les dépendances sont faibles, le risque est aussi limité. On fait avec les backports mais c'est pas officiel du coup, lors des upgrades, il y a parfois des difficultés. Et puis jouer avec les pinnings n'est pas toujours faciles.
[^] # Re: Une pression supplémentaire pour les développeurs
Posté par Etienne Bagnoud (site web personnel) . Évalué à 9.
PHP5 est sorti il y a 5 ans et généralement ce qui a disparu de PHP4 à PHP5 était noté comme obsolète dans PHP4.
Généralement les mises à jour sont pas si délicates que ça à faire et je trouve dommage qu'on essaie de ralentir l'évolution d'un système sous prétexte qu'un développement interne risque de ne pas fonctionner.
Une distribution ne doit pas être non plus l'accoudoir pour des systèmes obsolètes. Si en 5 ans rien ne peut être fait pour s'adapter à l'évolution, je doute que cela soit fait en 10 ans. Il suffit de regarder le cas des intranets, combien d'entreprise sont maintenant coincées avec un système ne fonctionnant correctement qu'avec IE 6[1]. Et plus on laisse aller plus ça va empirer.
Si les entreprises ne veulent pas investir dans l'évolution de leur système, elles investiront dans l'entretien de la distribution sous-jacente. Soit en achetant un support spécifique auprès d'un vendeur*, soit en maintenant en interne les paquets nécessaires. Mais ce n'est pas à la communauté de le faire.
Je suis certain qu'en commençant à faire comme ça, on pourrait trouver des raisons de maintenir la sécurité de la version 1.1, 1.2, ..., 5.0 !
Je penses qu'il faut garder un partage des tâches assez claire. La communauté développe une solution, elle est disponible durant un temps X (~3 ans), et passer à autre choses ensuite.
Et finalement, si on regarde, entre Etch et Squeeze, il n'y a pas (eu) de grands changements à prévoir dans la distribution de base.
[1] http://www.quirksmode.org/blog/archives/2009/06/state_of_the(...)
* Voilà un marché intéressant, maintenir la sécurité des versions obsolètes de système opensource,
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Une pression supplémentaire pour les développeurs
Posté par geb . Évalué à 2.
C'est ce que fait redhat non ?
Aie...
[^] # Re: Une pression supplémentaire pour les développeurs
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Une pression supplémentaire pour les développeurs
Posté par nodens . Évalué à 4.
Je serais assez de cet avis. Mais l'expérience me prouve le contraire. Même des mises à jour de version mineures posent parfois des problèmes majeurs. Le souci, c'est que le client qui a payé pour le développement d'un site ne voit pas pourquoi il devrait payer à nouveau un développement pour prendre en compte la mise à jour (souvent avec un autre prestataire), alors que ça « juste marche ». Du point de vue du client, ça se comprend, on n'a qu'à se démerder. Les marchés publics notamment ont une grande inertie. Bizarrement, la maintenance pour fonctionner avec un système plus récent n'est jamais comprise dans le marché :-)
Quant à dire que php5 est sorti il y a 5 ans, c'est vrai, mais je constate qu'il n'est pas répandu en entreprise depuis si longtemps que ça.
Par contre, personne ne m'a jamais demandé de faire tourner quelque chose en php3 depuis au moins 2001. Comme quoi c'est variable.
Les changements de la distribution de base ne me posent pas de problème. La libc, openssl, le noyau, ce genre de chose, sauf cas très particulier, c'est le problème de l'admin, l'applicatif n'a aucun impact : résultat on se débrouille. Les développements d'un client en php et mysql effectués avec un vieux « php pour les nuls » sous les yeux, c'est une autre paire de manche.
A la limite, les développements internes me posent moins de souci. On peut toujours, effectivement, faire la part des choses entre le coût d'administration d'un système obsolète et le coût d'une évolution du code. Mais le client ne veut pas avoir ce type de problèmes, sinon il ne prendrait pas de prestation d'infogérance.
Je n'ai jamais dit que ce type de support prolongé devait nécessairement être fourni par Debian, ni gratuit. Je pense que ça pourrait aussi se faire via une équipe de volontaires. Les entreprises intéressées contribueraient probablement du temps et des moyens.
N'empêche que ça m'arrangerait bien ! :-)
[^] # Re: Une pression supplémentaire pour les développeurs
Posté par Etienne Bagnoud (site web personnel) . Évalué à 4.
Dans un truc que je viens de faire, j'ai ceci "#define LDAP_DEPRECATED 1". Je sais que je vais être embêté, sûrement dans la prochaine version de Debian. Mais je vais pas blâmer quelqu'un d'autre que moi si mon programme ne fonctionne plus dans 2 mois.
Les développements d'un client en php et mysql effectués avec un vieux « php pour les nuls » sous les yeux, c'est une autre paire de manche.
Alors là c'est évident. Mais en même temps, tu n'as pas besoin de mettre à jour ton système, parce que les problèmes de sécurité vont venir de l'application du client : "include($_GET['page']);" et autre joyeuseté de ce genre. J'ai bossé dans une boîte qui faisait de l'hébergement, et bien les problèmes de sécurité venaient de ce genre d'application. La seule chose qu'on peut faire c'est limiter les dégâts, faire des sauvegardes régulières et passer à l'église tous les matins allumer un cierge.
Je n'ai jamais dit que ce type de support prolongé devait nécessairement être fourni par Debian, ni gratuit. Je pense que ça pourrait aussi se faire via une équipe de volontaires. Les entreprises intéressées contribueraient probablement du temps et des moyens.
Tu peux lancer le projet, mais je me vois la communauté faire ce genre de choses, car ceci bénéficie principalement à des entreprises qui font l'effort minimum au niveau informatique, donc s'attendre à ce qu'elles amènent quelque chose est illusoire. Mais en même temps je peux me tromper.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Une pression supplémentaire pour les développeurs
Posté par nodens . Évalué à 3.
C'est souvent le cas. Presque toujours, même. Mais le jour où la faille exploitée provient du système et non de l'application, tu auras un mal fou à expliquer que tu ne pouvais pas mettre à jour sans casser l'application (et en plus il se plaindra que tu n'avais qu'à utiliser une distribution avec un support plus long, enfin il le fera si il sait ce que c'est qu'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.