Squeeze freeze

Pause Café
#1

Salut,

Les dernières nouvelles concernant le gel de la version “Testing” actuelle, future “Stable”, la bien nomée SQUEEZE :118

Debian Project News - May 18th, 2010

Alexander Reichle-Schmehl

Squeeze freeze
--------------

Adam Barratt and the release team sent out an update on the status of
transitions, Release Critical bugs and a Timeline of the Squeeze freeze.
In short, we have a way to go before Squeeze is frozen and it is
difficult for the release team to estimate when Squeeze will get frozen.
Adam writes "In order to help us keep a clearer picture of which changes
still need to occur before we can freeze, we will be introducing a
'transition freeze' before the end of this month. If you have not yet
discussed your transition with the Release Team, please ensure that you
have done so before May 21st."

The release team is already working on some transitions now, like Qt4
and gnome-desktop, which are finished. The KDE team is working on KDE
4.4 with the goal of having as up-to-date and stable version of the KDE
suite as is possible. To quote Adam: "We're also close to completing the
evince / totem-pl-parser transition, which means we're well on the way
to have GNOME 2.30 in Squeeze."

"Even though the descending slope of theRC bug graph [8] is pretty
impressive [2], we still have about 400 RC bugs in Squeeze. Some of them
are waiting for packages to transition from unstable to testing, but
there's still a large number which need working on. On this every DD can
help out by NMUing packages which are currently affected by RC bugs.
Please remember that releasing is a collective effort and it is not
enough to just have your own packages RC-bug free (although it's a good
start) to be able to release. So, if you can help, please choose an RC
bug [9], fix it :-) and NMU it, possibly to the DELAYED queue so that
the maintainer can react if needed."

8 : http://bugs.debian.org/release-critical/
9 : http://bugs.debian.org/release-critical/debian/all.html

Par contre, je n’ai rien trouvé concernant la version du noyau… Personnellement, j’èspère que ce sera le 2.6.33(minimum) car il semblerait que la gestion des SSD y soit intégrée… à voir, donc.

Bonne journée à tous zé toutes,

Debcool

#2

Si la squeeze et pour bientôt, je pense que tu rêve pour la version du noyau ^^

#3

J’en ai bien conscience… mais vu que “l’explosion” des SSD arrivera fin de cette année(au niveau du grand publique), je pense que serait une “faille” (en terme de communication) exploitable par ceux qui dénigrent le “libre” en générale et Le projet Debian en particulier.

“Debian & Linux, c’est bien mais c’est toujours en retard… y gère même pas les SSD!” Le genre de petite phrase assassine que le grand publique(non avertis) avale bêtement sans se poser de question… et qui n’aide en rien la communauté, bien au contraire…

De plus, vu que le calendrier est déjà dépassé… bein, deux ou trois, quatre mois de plus n’y changera rien.

A l’inverse, si le support, même partiel, des SSD est intégré… une communication “positive” fera taire les mauvaises langues.

C’est un avis tout à fait personnel, évidement, et je suis conscient que le développement est loin d’être aussi simple à mettre en place.

A+
Debcool

#4

Je comprends ta remarque, mais à qui est destiné une stable principalement ? Aux serveurs … Est-ce qu’ils ont besoin de la gestion des SSD ?
En ce moment squeeze est en 2.6.30, mais les 2.6.33 et 2.6.34 ont du mal à intégrer SID, est-ce que c’est pour faire mûrir 2.6.32 en vu de son intégration dans Squeeze/Stable ?

#5

Pas tout à fait; lorsque je lis les difficultés rencontrées par les “débutants”(manque de connaissances de base), à mon sens, la “Stable” a tout à fait ça place ailleurs que sur les serveurs. Lorsque l’on éprouve déjà des difficultés à maîtriser un système, pourquoi se compliquer encore plus la tâche avec des versions “Testing ou Unstable”?

Je pense qu’il est préférable de commencer par être à l’aise avec la “Stable”, aussi “limitée” soit-elle, avant d’aller plus loin.

De plus, en entreprise, écoles…, on ne perdra pas du temps à bidouiller un peu tous les jours un parc entier de machines sous SID; une ou deux éventuellement mais on préférera la “STABLE” car tous les utilisateurs ne sont pas capable de gérer eux-même les soucis éventuels. J’irai même plus loin… Ils s’en cognent littéralement! Quant à ceux qui administrent, bein, ils ont sans doute autre chose à faire… quoi que…?

Ma compagne est sous Lenny “natif” et ça ne l’empèche pas de travailler malgré qu’elle soit dans un des domaines les plus “critiques” en termes de besoins d’innovations, la PAO et le web. Elle se démerde avec ce qu’elle a et, jusqu’ici, elle ne s’en plaint pas. Merci, chérie… :049

En ce qui concerne les SSD; Vu les gains de places, de performances, de souplesse et surtout, l’économie d’énergie… oui! Peut-être pas dans TOUS les contextes ni du jour au lendemain, ok, la deçus.

C’est ce que je pense aussi; et c’est bien celà qui m’ennuie, justement. J’aimerai pouvoir proposer aux gens qui m’entoure une version “Stable” qui correspond, dans les grandes lignes, à la réalité du marché car dès que les tailles vont augmenter et que les prix vont baisser, ils en voudront tous un… c’est sûr.

A+
Debcool

#6

Pourquoi ici : bugs.debian.org/release-critical/ il y a écrit qu’il y a 590 bugs alors que dans la news, il donne le nombre de 400 bugs?

#7

La page n’est sans doute pas à jour ?

#8

Salut,

Ces chiffres varient dans le temps; de plus il dit “we still have [color=#FF0000]about/color 400 RC bugs in Squeeze.”

A+
Debcool

#9

Enfin, « environ », je veux bien, mais là, on parle de 50 % de marge d’erreur! Y a pas 200 bugs ouverts ou fermés tous les jours, suffit de regarder le graphique pour s’en convaincre. Et la page est mise à jour automatiquement. À mon avis, il utilise d’autres chiffres. Mais lesquels?

#10

il parle peut-ête de ceux-ci:

et pas de ceux-là:

La question reste ouverte…

A+
debcool

#11

Ou alors il ne parle que des paquets contenus dans ‘main’ : bugs.debian.org/release-critical … /main.html

Sinon ptet qu’il y avait bien 400 RC bugs à un moment, et c’est remonté à environ 600 avec l’arrivée de KDE SC 4.4. siffle

#12

Pas tout à fait; lorsque je lis les difficultés rencontrées par les “débutants”(manque de connaissances de base), à mon sens, la “Stable” a tout à fait ça place ailleurs que sur les serveurs. Lorsque l’on éprouve déjà des difficultés à maîtriser un système, pourquoi se compliquer encore plus la tâche avec des versions “Testing ou Unstable”?

Je pense qu’il est préférable de commencer par être à l’aise avec la “Stable”, aussi “limitée” soit-elle, avant d’aller plus loin.
[/quote]
Je pense également que Debian n’est pas faite pour les débutants :wink:

#13

Est ce qu’il est possible de trouver quelquepart le programme d’intégration des nouveautés dans Squeeze ? c’est la dernière version du driver RADEON qui m’intéresse … elle dans Ubuntu 10.04 et dans SID mais pas dans le squeeze actuel.

Mon desktop va avoir une vocation de PC “ressource” , serveur Samba et backup et base de travail avec GUI pour installer des VM pour me faire la main donc j’aimerais rester en stable … Et virer ces #&#|@&# de pilotes ATI proprio.

#14

[quote=“debianhadic”]Je comprends ta remarque, mais à qui est destiné une stable principalement ? Aux serveurs … Est-ce qu’ils ont besoin de la gestion des SSD ?
En ce moment squeeze est en 2.6.30, mais les 2.6.33 et 2.6.34 ont du mal à intégrer SID, est-ce que c’est pour faire mûrir 2.6.32 en vu de son intégration dans Squeeze/Stable ?[/quote]
C’est exactement ça. Il a était décidé que Squeeze comme Fedora 13 et d’autre seras en 2.6.32.

Par contre il est facile d’upgrader le noyau d’une stable et, comme pour lenny, le noyau seras mis à jour de temps en temps.

#15

Les développeurs du noyau Linux n’ont pas une influence pour le choix du noyau des grandes distributions maintenues à long terme ? Ce sont quand même les 1er concernés lors de la correction de bugs.
Je crois que ça avait un peu râlé chez les dev Linux quant au choix du 2.6.26 pour Lenny…

Le 2.6.32 sera utilisé par Debian 6, Ubuntu 10.04 et RedHat 6, ça doit faciliter la vie aux devs pour se concentrer sur la maintenance de cette version.

#16

Tu pense qu’ils arrivent à se mettre d’accord sur ce genre de choses à la LKML ? De plus Red Hat embauche des développeurs du noyau donc ils sont au fait des enjeux que cela comporte.

#17

Je ne sais pas, c’était plus ou moins une question. J’ai juste souvenir d’un épisode sur la LKLM où ça grognait pour le noyau de Lenny. Mais pour retrouver les liens… possible que c’était des dev de chez RedHat :stuck_out_tongue:

Ce n’est sûrement pas anodin le fait que 3 distributions majeures aient choisi une même version du noyau. Et même si c’était le fruit du hasard, c’est une bonne chose pour cette release.

#18

Squeeze est en 2.6.32 il me semble actuellement, et ça doit déjà faire un petit moment.

En tout cas, il est vrai que Squeeze était prévu avec le noyau 2.6.32, mais il y aura certainement la possibilité d’en choisir des plus récents.

#19

Je rebondis un peu à la bourre sur la question des SSD. Ils ne sont vraiment pris en compte qu’à partir du 2.6.33 ? Je comptais m’en offrir un dans les mois qui viennent, mais donc aucune chance d’installer une stable avec noyau 2.6.32 backporté dessus, ça sera pas reconnu ?
Et même quand Squeeze sera stable, son installateur reconnaitra-t’il le SSD pour s’installer dessus ? :017

#20

Je ne comprends pas vos histoires de SSD, un eeepc 701 fonctionne sous debian avec un SSD (de 4gb) depuis près de deux ans chez moi. Ne serait-ce pas plutôt la gestion “intelligente” des SSDs qui est implémentée dans les noyaux récents ou alors ce qu’on appelait SSD il y a deux ans est tout autre chose aujourd’hui? Éclairez ma lanterne.