L'équipe Debian a sorti récemment la deuxième version candidate de Debian Installer pour Debian Lenny. les tests de cette version sont très encourageants. L'équipe entre dans la phase finale appelée deep freeze. Pendant cette période, seuls les bogues critiques seront corrigés, le reste restant gelé. Les développeurs de Debian pensent donc que la sortie de la version définitive de Lenny devrait intervenir durant le week-end du 14 février. Les bogues non critiques non corrigés seront intégrés lors de la sortie de la première version r1 de Lenny. De plus, il y aura une version "Lenny and a half" au milieu du cycle de développement de Squeeze, la prochaine version de Debian après Lenny.
http://lists.debian.org/debian-devel-announce/2009/02/msg000(...)
# ...
Posté par IsNotGood . Évalué à 2.
[^] # Re: ...
Posté par vida18 . Évalué à 2.
[^] # Re: ...
Posté par tuXico . Évalué à 3.
En même temps, l'annonce de la date de release de debian est importante je pense pour pas mal de visiteurs de dlfp (perso j'attends la sortie du freeze...)
NB : Comme rappelé par misaine sur debian-fr "il est temps pour ceux qui sont en testing de vérifier leur sources.list pour ne pas se retrouver avec une \"nouvelle testing\" toute bancale"
# Le 14 Février
Posté par Johan Charpentier (site web personnel) . Évalué à 10.
Ça plus l'AG de l'APRIL le même jour, faut pas s'étonner que les geeks soient une majorité de célibataires....
[^] # Re: Le 14 Février
Posté par gorva . Évalué à 9.
[^] # Re: Le 14 Février
Posté par dyno partouzeur de drouate . Évalué à -2.
Il faut dire que l'accumulation de négations est très moche et n'aide pas du tout à comprendre. Donc finalement, ces bugs qui ne sont pas critiques et qui ne sont pas corrigés seront intégrés dans la r1. Intégrer un bug non corrigé, ça veut bien dire le laisser à l'état de bug non ?
[^] # Re: Le 14 Février
Posté par tuXico . Évalué à 0.
[^] # Re: Le 14 Février
Posté par pitch78 . Évalué à -1.
# Seuls les bogues critiques seront corrigés
Posté par dyno partouzeur de drouate . Évalué à -8.
Debian c'était mieux quand ça sortait "when it's done" !
[^] # Re: Seuls les bogues critiques seront corrigés
Posté par Aefron . Évalué à 4.
[^] # Re: Seuls les bogues critiques seront corrigés
Posté par Aefron . Évalué à 10.
... si les bugs sont critiques pour la sortie ("release-critical"), et bien, la règle est de les corriger pour officialiser la sortie (c'est le principe :p)... quant aux bugs corrigés, critiques ou pas, s'ils sont corrigés, euh... la question est donc bien celle des bugs non-critiques, et non-corrigés (ce qui n'est pas _une_ double négation, mais _deux_ négations en parallèle : nuance).
Maintenant, il y a des choses qui sont encore à la bourre... et qui ne sont pas encore intégrées à Lenny du tout, ce qui peut impliquer la disparition du paquet de Lenny (temporaire... ou pas), et sa présence uniquement dans Etch (vieille version) et Sid (version sur laquelle les intégrateurs travaillent, et qui rejoindra Lenny en temps utile, si elle finit par le faire, post-r0). Ça peut impliquer aussi le déclassement d'un bug comme étant "release-critical" vers un état moins grave (par exemple "can-defer", ie "peut attendre")...
L'intérêt ? Ne pas rajouter de bugs "release-critical", ni s'en encombrer, pour quelques trucs qui sont à la bourre, ce qui pénaliserait tout le monde à cause d'une minorité.
Exemple ? Mondo Rescue/Mindi [1]... Plein de problèmes dans la version de Sid, et, il me semble, comme l'un des devs du projet est mainteneur Debian, il a l'air d'avoir envie d'attendre un peu avant d'uploader la nouvelle version dans Lenny... surtout que, sur la page du projet, dans les dernières nouvelles [2], on peut voir qu'il y a eu du boulot sur Mindi spécifiquement (entre autres) pour Lenny. Bref, ce serait dommage de rester sur l'ancienne version, tout autant que mettre un truc pas prêt dans Lenny.
Autre exemple ? Le support du client NFS dans les conteneurs OpenVZ [3] ... le mainteneur explique clairement que le patch upstream le permettant étant clairement un casseur d'ABI, ce patch ne pourra être intégré que dans la version r1, le temps d'être sûr que, quitte à les casser, qu'il n'y ait au moins pas à le faire 36 fois, mais seulement quand le noyau de Lenny est bien défini.
Et puis, n'oublie pas : tu as un an de support de Etch, à compter de la sortie de Lenny... Ça va : il n'y a pas le feu au lac qui te force à migrer, là, dans 10 jours, hein...
Évidemment, tout ne sera pas parfait à la sortie : il restera des trucs pas finis, et de toute façon, on découvrira de nouveaux bugs au fur et à mesure du temps. Maintenant, j'ai signalé assez tôt ce qui me gênait le plus pour Lenny, et pour le reste, et bien je ferai avec (ne pas oublier non plus que, quelque temps après la sortie de Lenny, Testing, qui sera alors Squeeze, viendra à gagner un support de sécurité, et pourrait devenir raisonnablement utilisable dans des cas où Testing ne l'était pas, avant).
Bref, vivement le dégel : ça fait ~6 mois que ça a freezé... Sid est freezée... c'est nécessaire, mais point trop n'en faut non plus. Il est temps de s'agenouiller devant la nouvelle Debian (et que j'arrête de me prendre le choux avec le X.org d'Experimental, pour avoir de nouveau une Sid plutôt à jour, sans être cassée) :p
[1] http://packages.debian.org/search?keywords=mondo
[2] http://www.mondorescue.org/
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501985
# Freespire
Posté par vida18 . Évalué à 3.
# Bientôt KDE 4.2
Posté par Xavier Teyssier (site web personnel) . Évalué à 7.
[^] # Re: Bientôt KDE 4.2
Posté par byrad . Évalué à 1.
J'ai essayé KDE4.2 avec le dépot experimental et le résultat était catastrophique, voire complètement inutilisable alors qu'avec la version 4.1 j'ai pu pu longuement tester sans plantages ni ralentissement.
Bref, vivement KDE4.2 dans sid, mais pas trop vite ...
[^] # Re: Bientôt KDE 4.2
Posté par Xavier Teyssier (site web personnel) . Évalué à 3.
Je ne pense pas que grand monde utilise experimental.
[^] # Re: Bientôt KDE 4.2
Posté par Anonyme . Évalué à -6.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.