Le cycle de développement est trop long, c'est l'inverse qui se produit. En théorie, c'est la bonne méthode, et ça marche avec tout ce qui est serveur, mais en pratique et avec les desktop, ça ne marche pas à cause de leur rythme de release sur 6 mois.
Un exemple que j'ai eu avec debian 4.0, c'est un bug de konqueror qui le faisait planter qui était corrigé dans KDE depuis un an, donc dispo dans les distros "6 mois" depuis un an en update et intégré dans les version récentes depuis 9 mois. En installant debian "stable" je retrouvai ce bug et put planter mon navigateur simplement en visitant un site. Ce n'est passtable, ça.
Un autre exemple c'est le KDE de debian stable, c'est le 3.5, donc c'était certainement la chose à faire par rapport à KDE4.0 mais maintenant, KDE 3.5 n'est pas le KDE le plus stable. Une des raisons de faire KDE4 c'est que les bug fixes en amont chez trolltech sont allés à partir d'un certain moment dans qt4. Donc avoir KDE3 ce n'est pas avoir le Qt le plus stable.
Debian stable ne veut pas dire les logiciels sont le plus stables possible, ça veut dire l'installation est stable, nos paquets n'ont pas de problèmes entre eux sur toutes les plateformes supportés, et on intègre le logiciel X le plus stable possible en version Y. Mais tu restes avec la version Y trop longtemps même s'il y a une versions Z plus stable depuis.
C'est ce qui permet aux admins sys de l'installer au travers du net en toute confiance.
A l'autre bout du spectre, les distros qui se calent sur les release de 6 mois ne peuvent pas être stables non plus puisqu'elles intègrent les bug fixes dont je parlais certes, mais aussi les régressions que les nouvelles fonctionnalités apportent.
De plus, les release de desktop sont inégales, même s'ils se calent sur 6 mois, certaines contiennent plus de bugfixes, d'autre plus de fonctionnalités donc plus de régressions, donc le travail à leur apporter est plus ou moins grand ou demande plus de temps à attendre les fixes des régressions.
Donc le bon comportement est au minimum de se caler sur les release de 6 mois des desktop plus x mois de fix plus y semaines d'intégration. X étant variable à la "qualité" de la release du desktop modulo l'équipe de la distro, y étant variable à la quantité de personnalisation que la distro apporte au desktop, presque 0 pour ceux qui releasent du "vanilla".
Ca fait des release de sortie variables mais restant synchronisé sur les release de desktop.
Et de fournir une infrastrucure de backports efficace pour pouvoir disposer des nouvelles fonctionnalités sur les anciennes versions ou participer aux versions de développement de desktop sans passer aux versions de développement de la distro.
C'est ce que font les gens expérimentés de facto sur debian en ne restant pas en stable qu'ils l'utilisent en desktop, ou sur les distros "6mois" en n'installant pas la dernière immédiatement, LTS et autre BS ou pas, soit en attendant plusieurs mois le bon niveau de bugfixes dans les updates, soit carrément en sautant des release.
[^] # Re: Propre
Posté par imr . En réponse à la dépêche Sortie de Pardus 2009.2 (Geronticus eremita). Évalué à 4.
Un exemple que j'ai eu avec debian 4.0, c'est un bug de konqueror qui le faisait planter qui était corrigé dans KDE depuis un an, donc dispo dans les distros "6 mois" depuis un an en update et intégré dans les version récentes depuis 9 mois. En installant debian "stable" je retrouvai ce bug et put planter mon navigateur simplement en visitant un site. Ce n'est passtable, ça.
Un autre exemple c'est le KDE de debian stable, c'est le 3.5, donc c'était certainement la chose à faire par rapport à KDE4.0 mais maintenant, KDE 3.5 n'est pas le KDE le plus stable. Une des raisons de faire KDE4 c'est que les bug fixes en amont chez trolltech sont allés à partir d'un certain moment dans qt4. Donc avoir KDE3 ce n'est pas avoir le Qt le plus stable.
Debian stable ne veut pas dire les logiciels sont le plus stables possible, ça veut dire l'installation est stable, nos paquets n'ont pas de problèmes entre eux sur toutes les plateformes supportés, et on intègre le logiciel X le plus stable possible en version Y. Mais tu restes avec la version Y trop longtemps même s'il y a une versions Z plus stable depuis.
C'est ce qui permet aux admins sys de l'installer au travers du net en toute confiance.
A l'autre bout du spectre, les distros qui se calent sur les release de 6 mois ne peuvent pas être stables non plus puisqu'elles intègrent les bug fixes dont je parlais certes, mais aussi les régressions que les nouvelles fonctionnalités apportent.
De plus, les release de desktop sont inégales, même s'ils se calent sur 6 mois, certaines contiennent plus de bugfixes, d'autre plus de fonctionnalités donc plus de régressions, donc le travail à leur apporter est plus ou moins grand ou demande plus de temps à attendre les fixes des régressions.
Donc le bon comportement est au minimum de se caler sur les release de 6 mois des desktop plus x mois de fix plus y semaines d'intégration. X étant variable à la "qualité" de la release du desktop modulo l'équipe de la distro, y étant variable à la quantité de personnalisation que la distro apporte au desktop, presque 0 pour ceux qui releasent du "vanilla".
Ca fait des release de sortie variables mais restant synchronisé sur les release de desktop.
Et de fournir une infrastrucure de backports efficace pour pouvoir disposer des nouvelles fonctionnalités sur les anciennes versions ou participer aux versions de développement de desktop sans passer aux versions de développement de la distro.
C'est ce que font les gens expérimentés de facto sur debian en ne restant pas en stable qu'ils l'utilisent en desktop, ou sur les distros "6mois" en n'installant pas la dernière immédiatement, LTS et autre BS ou pas, soit en attendant plusieurs mois le bon niveau de bugfixes dans les updates, soit carrément en sautant des release.