On Fri, 13 Sep 2002 12:46:18 +0200
Igor Genibel <[EMAIL PROTECTED]> wrote:
> Pour que ce genre de probl�me arrive moins souvent (bien que ce soit
> relativement rare) il est de notre devoir de tester les packages
NB : "notre" = mainteneurs Debian ??
Les mainteneurs/d�veloppeurs d�veloppent, les utilisateurs utilisent.
> avant qu'ils rentrent dans la branche stable.
> le valider. Je ne cesserai de le r�p�ter � tout va que l'utilisation
> de querybts et de reportbug devraient �tre obligatoire et devenir un
> r�flexe. Ceci permettrait donc d'avoir moins de surprises
> d�sagr�ables.
Faut pas non plus se moquer du monde...
Je veux bien tester mais QUAND JE LE CHOISI... i.e quand je sais o� je
mets les pieds !!
En l'occurence, sans vouloir �tre m�chant avec le mainteneur, webmin
est fait pour administrer des (remarquez le pluriel) machines �
distance, webmin �tait dans potato et fonctionnait correctement.
webmin est maintenant dans woody. Stable �a veut dire qu'un service
op�rationnel auparavant le reste apr�s mise � jour. Fallait 5 minutes
et au moins deux machines pour voir que ce n'�tait pas le cas. C'est
quand m�me pass� dans stable... � qui la faute?
Deux choses :
* si le processus de diffusion Debian est incapable d'assurer une
v�ritable s�mantique du mot "stable", faut le dire. Point barre.
J'ajoute qu'il n'y aurait aucune raison d'avoir honte, c'est quasiment
impossible de nos jours...
* pour valider un paquet comme webmin, faut un contexte minimum
(quasiment une �quipe) [encore faudrait-il ici faire la diff�rence
entre stabilit� upstream et stabiliy� du paquet].
On pourrait retourner la remarque ainsi : c'est trop facile de se
mettre mainteneur d'un paquet (et �tre sur la photo de classe Debian)
en se reposant sur les users derri�res pour balayer.
(Profitons-en!!) En ce qui concerne le devoir d'obligation d'utiliser
reportbug et cie, j'aimerai bien dans ce cas (obligation vers les
users) qu'il existe �galement une obligation (pour les mainteneurs) �
construire leur paquet dans un chroot/pbuilder (par exemple). �a
�viterait d�j� bien des probl�mes. �videmment c'est plus lourd, ok.
Mais la robustesse d'une distribution est � ce prix.
[ajoutons : isoler les param�tres de configuration, pr�server les
options de configuration des applis en amont, ne pas choisir pour moi
si j'utilise gnome ou kde, si j'utilise mysql ou postgresl, pr�server
la d�tection optimale du cpu, ne pas modifier les pieds de pages des
docs fournies, ... des tas de trucs
tout �a c'est du v�cu �videmment...
]
En faisant du backport, j'ai rencontr� pas mal de trucs marrants, j'ai
fait quelques rapports. Mais d'un autre c�t� je vois pas pourquoi je
passerai un bon quart d'heure (pour le faire bien) � rapporter un
probl�me qui se d�tecte en 5 minutes au d�part. � la fin �a devient
p�nible.
Tiens, je crois savoir que tu es d�veloppeur, si tu pouvais faire
passer le message, ce serait sympa...
A+
--
mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06
INRETS, 20 rue �lis�e Reclus fax: (33) 03 20 43 83 59
BP 317 -- 59666 Villeneuve d'Ascq
http://www3.inrets.fr/estas/mariano
