Re: Webmin buggué (stable) ?
On Fri, 13 Sep 2002 12:46:18 +0200
Igor Genibel <igor@genibel.org> 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:georges.mariano@inrets.fr 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
Reply to: