Re: Passage de lenny à squeeze
Le mercredi 18 février 2009, Goldy a écrit :
> Mathieu JANIN a écrit :
> > Bonjour,
> > sur une machine critique, aucun interet de passer en squeeze, ça va être
> > pendant minimum un an la pire des trois solutions entre lenny, squeeze,
> > et sid. Les paquets arrivant seront dans un état de compatibilité entre
> > eux absolument non testés en plus du fait que la sécurité de chaque
> > paquet n'est pas garantie, et les versions vont commencer à se succèder à
> > rythme rapide en squeeze dans ce contexte instable. Ceci contrairement à
> > la sid qui évolue sans à coup (un petit peu de mouvements avec la sortie
> > de lenny, mais le dist-upgrade s'est fait sans incident pour moi) et
> > malgré l'absence d'équipe sécurité et de menus défauts, reste plus stable
> > que nombre de distribs annoncées comme des produits finalisés.
> > Pour l'instant, donc, la squeeze va être destinée surtout aux bénévoles
> > prets à se prendre les pires bugs en pleine face.
> > Si tu veux des logiciels "cutting edge" prends une sid. Si tu ne veux
> > pas prendre de risque, restes en Lenny. La squeeze, c'est pour rendre
> > service aux autres en remontant les bugs.
> >
> > ++, MATT
>
> C'est surprenant que squeeze soit plus "dangereux" que sid, car selon ce
> que l'on peut lire sur le site de debian, les paquets arrivant sur
> squeeze doivent d'abord passer par sid pendant un certain temps.
>
> Il semble que la mise des paquets depuis sid dans la testing soit fait
> automatiquement d'ailleurs.
Tu mettrais en doute ma bonne parole mécréant ?
Lis sur mes lèvres.
;)
.>Chaque< paquet dans testing est une version plus stable dans l'absolu qu'un
paquet de sid, oui, mais juste aprés le lancement d'une nouvelle testing, les
paquets de sid >entre eux< sont plus bien plus compatibles que ceux de la
testing >entre eux< au niveau de version ou ils en sont, car pour débuguer
les problêmes >à l'intérieur des paquets< en sid, les développeurs ont
tendance à lisser d'abord les bugs les plus dramatiques avec les paquets
corrèlés, pour pouvoir bosser tranquillement sur les problêmes qui concernent
la sid (l'intérieur des paquets). Du coup, une testing est >globalement< bien
plus buguée à son début que la sid (la sid restant presque toujours
parfaitement exploitable pour une machine perso).
Avec l'approche de la stabilisation de la testing et le ralentissement de
l'importation de nouvelles versions, la situation s'inverse, jusqu'au freeze,
ou le débuguage >d'interaction entre les paquets< arrive à sont sommet... Et
c'est la release, mais c'est la dernière étape.
Enfin généralement, et d'un point de vue totalement personnel et subjectif,
parceque je l'ai vécu plusieurs fois, et parceque c'est la seule explication
qui me permette d'expliquer le quasi monopole de gueulantes concernant la
testing sur les forums juste aprés la release d'une nouvelle stable.
C'est pas du bronze, juste un constat.
C'est mieux comme explication ?
Reply to: