Re: suppression d'amarok + k3b sous testing (etch)
Le Mon, 21 Nov 2005 07:10:10 +0100, Thierry B a écrit :
> Car pour moi l'avantage d'une testing, c'etait d'avoir moins de bugs dans
> les paquets du fait, que la maj se fera dans plus de temps, non?
Si tu veux dire qu'un paquet testing comporte moins de bug qu'un paquet
unstable du fait de la "retenue" en amont/sid et donc de la correction
potentielle de bug avant l'entrée dans testing ben : bof.
Schématiquement, on peut imaginer que :
* les premiers bugs corrigés sont les plus grossiers, essentiellement dus
à la construction même du paquet (mauvaises dépendances, plantage de
scripts d'install)
* ensuite, il _faut_ attendre testing pour que le nombre de contextes
d'installation augmente considérablement et définisse alors une
couverture de test suffisant pour découvrir les bugs plus subtils
Ensuite, il faut prendre en compte une deuxième dimension pour évaluer
la fiabilité d'un paquet, c'est sa "hauteur" dans l'arbre des
dépendances. En "bas" de l'arbre,on trouve les librairies de base
(exemple suprême la libc6), en haut les applications (au hasard amarok).
La fiabilité des paquets est liée au nombre d'installation (et donc de
tests effectifs) de ces paquets. La libc6 est évidemment parmis les
paquets les plus testés alors qu'une application n'est testée que par
ses utilisateurs... Là-dessus faire un ratio pour déterminer la
population qui fera effectivement des rapports de bugs pertinents.
Donc globalement, au sens mathématique, il y a moins de bugs dans testing
que sid, mais il est pas évident que la population des
bugs-"utilisateurs" soit nettement plus petite. La question n'est pas
tellement d'être ou pas en sid/testing mais plutôt quelle est la
maturité du paquet (saut de version au niveau de l'application, saut de
version au niveau du paquet)
A+
--
mailto:mariano.georges@free.fr jabber:georges.mariano@jabber.org
val-libre : http://www.mjc-athena.org/val-libre
Reply to: