Deux de plus. Merci d'avance pour vos relectures. -- Thomas Huriaux
#use wml::debian::weeklynews::header PAGENAME="Courriel"
#use wml::debian::translation-check translation="1.9" maintainer="Thomas Huriaux"
<a name=1></a>
<pre>
À : debian-policy@lists.debian.org
Sujet: Re : La description de la procédure ne remplace pas la compréhension
De : Manoj Srivastava <srivasta@debian.org>
Date : 24 mars 2000 09 h 47 ' 03 " -0600
>>"Ian" == Ian Jackson <ian@davenant.greenend.org.uk> a écrit:
Ian> Je pense que le problème fondamental est que le manuel de la charte
Ian> a besoin d'être cohérent et bien pensé, ce qui signifie qu'il doit
Ian> être écrit par une ou plusieurs personnes excellentes au niveau
Ian> technique, qui ont la capacité d'anticiper les problèmes et qui
Ian> n'ont pas peur de mettre leur opinion en pratique (après des
Ian> discussions, bien sûr).
Personnellement, je ne pense pas qu'il s'agisse de la seule manière
dont les choses doivent être faites. Je trouve que la plupart des standards
ne sont en fait pas créés par quelques figures héroïques ; les groupes
de travail de IETF, IEEE et ISO ne sont pas que des « experts
techniques ». Si notre charte était de la même qualité que les documents
produits par ces entités, je serais déjà content.
En effet, le paragraphe ci-dessus démontre les limites de la
position de Ian : elle concentre le pouvoir entre quelques mains
seulement et même si celui-ci n'est pas absolu, nous savons tous comment
la dernière élaboration centralisée de la charte a fini.
Deuxièmement, elle ne prend pas en compte la nature du projet :
il s'agit d'un projet composé de volontaires, et les exigences de
notre travail dans la vie réelle sont prioritaires pour la plupart
d'entre nous. Même Ian et moi ne sommes pas toujours présents,
nous ne pouvons donc pas laisser reposer le projet sur les épaules
de quelques rares personnes.
Ce que Ian dénigre au niveau procédure et bureaucratie, c'est
qu'il s'agit principalement d'un mécanisme mis en place pour être sûr
que personne ne soit désigné responsable de la charte en permanence --
et que les personnes qui s'en occupent puisse aller et venir comme bon
leur semble.
Ian> Nous ne devons pas continuer à maintenir la charte de manière
Ian> à ce que les décisions (a) soient prises par quelques-uns de
Ian> nos (environ 400) développeurs - parmi lesquels tous ne sont pas
Ian> excellents techniquement parlant - si insuffisamment de personnes
Ian> sont présentes au bon moment pour contester ; et la mise en
Ian> application des décisions (b) ou certaines bonnes décisions
Ian> sont bloquées, car soit quelqu'un qui n'est pas compétent dans
Ian> le domaine concerné ne les comprend pas et conteste, soit
Ian> le point concerné tombe dans l'oubli ou n'a pas attiré
Ian> suffisamment de « moi aussi ».
Oui. L'actuelle procédure pour la charte est difficile à accepter
par quelqu'un qui croit en l'efficacité fondamentale de l'élitisme. (Je
ne désire offenser personne.) L'actuelle procédure pour la charte suppose
que les développeurs sur -policy ont les compétences minimales nécessaires,
ou qu'il y a suffisamment de personnes techniquement compétentes sur
-policy pour faire ce travail.
Je ne dis pas qu'il n'y a pas de problèmes dans l'approche
actuelle -- nous avons besoin d'un coordinateur (ou d'un groupe de
coordinateurs ?) pour gérer certaines des questions que Ian a soulevées :
a) avoir un pouvoir délégué par le chef du projet pour rejeter
les contestations « non fondées » ;
b) débloquer les discussions sans fin en tranchant quand il
faut ;
c) créer un rapport périodique de l'état de la charte pour
conserver l'attention ;
d) refuser les propositions « non sexy ».
Ian> Pour prendre quelques exemples, le bogue que j'ai réouvert au
Ian> début de cette enflammade est tombé dans la catégorie (b), et
Ian> la décision de changer la référence à FSSTND en une référence à
Ian> FHS, sans écrire de plan de transition, est un cas de (a).
Il me semble que beaucoup de personnes techniquement excellentes
n'ont pas fait attention à (a), et faire de quelqu'un techniquement
excellent un éditeur de la charte est voué à l'échec, comme on ne
peut pas forcer un volontaire à travailler ; ou peut-être que (a) était
plus difficile que prévu ?
Ian> Cette dernière décision a coûté pas mal de temps à la plupart
Ian> des personnes dans le projet, et a probablement (en gaspillant
Ian> les efforts pour résoudre ce problème au lieu de faire du travail
Ian> utile) provoqué des dommages invisibles (un logiciel ne trouve
Ian> parfois pas les fichiers info ou les pages de manuel, etc.).
C'est ironique, si l'on considère que la majorité du chahut a été
créée car les personnes responsables de dpkg (à qui tu veux donner le
pouvoir absolu pour l'élaboration de la charte) ont négligé dpkg, donc
la solution la plus simple est devenue impossible, puisque les changements
à dpkg semblaient nécessiter un bouleversement énorme pour ce point.
La distribution instable casse. Et le travail réalisé par les
gens aurait de toute façon été nécessaire pour migrer vers le système
de hiérarchie des fichiers. Et nous devons migrer pour garder la
compatibilité avec le reste de la communauté Linux. Conserver la
compatibilité est vital pour Debian.
Les suppositions étaient que :
a) le problème du lien symbolique n'était pas insurmontable pour les
développeurs ;
b) une fois que les paquets d'aide étaient modifiés, environ 60 % des
paquets devaient être conformes (supposition : les auteurs du paquet
helper sont compétents) ;
c) les gens qui n'utilisent pas les paquets d'aide étaient suffisamment
malins pour réussir à gérer un lien symbolique eux-mêmes ;
d) il n'y a pas tant de programmes qui utilisent le répertoire doc ;
e) les gens qui maintiennent des programmes qui utilisent le répertoire
doc étaient compétents pour que ces programmes utilisent les deux
emplacements.
Il semble que le dernier point n'ait pas été totalement vérifié.
Cependant, aucun éditeur de la charte, quelle que soit sa
compétence, n'aurait pu changer ce dernier point, puisque nous n'aurions
pas pu nous occuper de tous les paquets pendant la transition.
Ian> Nous devons enlever le contrôle de nos standards techniques clés
Ian> d'une liste de diffusion et le rendre à des experts techniques !
Je trouve cette sorte d'élitisme exagéré, et pire, ingérable
dans le cadre de fonctionnement du projet. Nous devons nous décentraliser
pour croître, et pas retourner à une procédure centralisée qui a déjà
échoué.
Ian> De même, je pense que nous devons arrêter de faire la distinction
Ian> entre la charte et le manuel pour les logiciels de base. Quand
Je ne pense pas qu'il s'agisse d'une fausse distinction.
L'implémentation d'un compilateur C ne décide pas du langage. Il en est
de même pour l'implémentation du gestionnaire de paquets.
Tu sembles avoir plus confiance en les personnes qui programment
dpkg que moi. Et comme les programmeurs de dpkg ont changé, et, en
effet, il y a eu de nombreuses NMU sur ce paquet venant de nombreuses
personnes différentes, je trouve ici ta position assez contradictoire.
De plus, j'ai vu le code de dpkg. J'ai été dépité par la qualité
de ce code, et cela me pousse à avoir encore moins de confiance pour
les compétences techniques démontrées là-dedans. Il s'agit d'une
opinion personnelle, mais justifiée, je pense, même si elle doit sembler
sévère. Si nous n'étions pas en train de parler de quelque chose que
je considère critique pour le projet, je n'aurais pas dit cela, et je
m'en excuse. Je sais que cela ressemble à des attaques personnelles, mais
j'essaie de proposer un jugement objectif.
Ian> Je pense que (par exemple) le responsable de dpkg devrait avoir les
Ian> pouvoirs absolus pour écrire le manuel du programmeur de dpkg, et
C'est vrai. Mais le manuel du programmeur de dpkg n'est en aucun
cas la charte, et en effet, dpkg se doit d'être conforme à la charte,
et pas à autre chose.
Ian> que les paquets doivent être conformes aux exigences du manuel.
Ian> Les responsables des paquets qui, par leur position, définissent
Ian> des standards pour les autres paquets, ne devraient pas avoir à
Ian> venir ici et à s'engager dans une procédure complexe et
Ian> bureaucratique pour documenter le comportement de leur programme !
C'est faux. Les responsables de ces paquets doivent se conformer
à la charte, et s'ils ne peuvent pas ou ne veulent pas, alors nous
devons chercher un paquet qui puisse le faire. La tyranie des
gestionnaires de paquet monopolistiques a plombé le projet dans le passé,
et nous devons nous en débarasser.
manoj
--
L'histoire a tendance à exagérer. Col. Green, « The Savage Curtain »,
stardate 5906.4
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
</pre>
<hr>
<a name=2></a>
<pre>
À : Ian Jackson <ian@davenant.greenend.org.uk>,
Wichert Akkerman <wichert@cistron.nl>
Cc : debian-policy@lists.debian.org
Sujet : Discussion sur IRC à propos de la charte
De : Manoj Srivastava <srivasta@debian.org>
Date : 27 mars 2000 15:08:04 -0600
Salut,
Wichert a suggéré une rencontre sur IRC, pour discuter sur
-policy. La discussion est ouverte à tout le monde (irc.debian.org), mais
pourrait être modérée et en lecture seule, sur un canal à décider.
Comme mercredi semble être le jour le plus proche qui pourrait
convenir, que pensez-vous de cet horaire ?
Mercredi 29 mars
18:00 CET
16:00 GMT
10:00 CDT
Je dois avouer que je ne suis pas à l'aise sur ce sujet. Les
positions et les arguments ont été présentés sur la liste de diffusion.
Une rencontre irc est utile s'il y a des ambiguïtés, ou s'il y a
une possibilité de convergence des points de vue. Je suis toujours ouvert
pour écouter et participer à une discussion, mais je pense que les
positions sur -policy sont trop éloignées, et je suis suffisamment
habitué pour être sceptique sur les chances de convergence grâce
à une discussion informelle.
Je désire être agréablement surpris.
manoj
--
Espérez que l'inspecteur-vie n'apparaîsse pas lorsque votre vie est dans
un tel chaos.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
</pre>
#use wml::debian::weeklynews::footer translator="Thomas Huriaux"
#use wml::debian::weeklynews::header PAGENAME="Courriel"
#use wml::debian::translation-check translation="1.4" maintainer="Thomas Huriaux"
Un peu plus de courriels que d'habitude ; les archives des listes
sont partiellement cassées.
<p>
<a name=1></a>
<pre>
Date : Mar. 18 avr. 2000 13 h 47 ' 46 " +0200
De : Richard Braakman <dark@xs4all.nl>
À : debian-release@lists.debian.org
Sujet : Préparation du premier cycle de tests
Sera-t-il possible de commencer le premier cycle de tests aux environs
du 2 mai ? C'est dans deux semaines.
Cela signifie que le 2 mai sera le dernier jour pour mes changements dans
Potato, à l'exception de ceux nécessaires pour avoir des disquettes
de démarrage et des images de cédérom qui fonctionnent. Il y aura
quelques jours prévus pour cela.
Après une période de tests de durée déterminée, nous évaluerons les
résultats et déciderons de publier ou pas ce que nous avons.
Richard Braakman
</pre>
<hr>
<a name=2></a>
<pre>
Date : Sam. 15 avr. 2000 17 h 41 ' 55 " -0400
De : Wichert Akkerman <wichert@mors.wiggy.net>
À : debian-dpkg@lists.debian.org
Cc : debian-devel@lists.debian.org
Sujet: mise à jour de l'état du code de dpkg
--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Une mise à jour de l'état pour les personnes qui se demandent ce qui va
se passer avec dpkg dans Woody.
Les changements suivants ont déjà été faits dans le CVS :
* Le format des .changes a été mis à jour pour séparer les champs
Changed-By et Maintainer. Changed-By est la dernière personne qui a
modifié le paquet, comme signifié dans le fichier debian/changelog,
et Maintainer est le responsable actuel comme signifié dans le
le fichier debian/control.
* dpkg-deb a été modifié pour réorganiser les fichiers lors de la
construction d'un paquet. Cela signifie que vous n'avez plus à créer
les liens symboliques après leur cible, et rend possible la construction
des paquets sur des systèmes de fichiers avec différents comportements
des répertoires, comme reiserfs.
* Utilisation d'objdump à la place de ldd pour obtenir la liste des
bibliothèques qu'un binaire utilise.
* Mises à jour de la portabilité. À l'exception de l'utilisation de
ENOENT dans les scripts perl, dpkg se compile désormais sur hurd sans
changement. Les problèmes avec ENOENT sont un bogue dans perl-base
qui a été soumis il y a des mois.
* Les variables de substitution dpkg:UpstreamVersion et dpkg:Version
peuvent être utilisées dans les fichiers control et changes.
Les choses suivantes sont encore à faire et apparaîtront certainement
dans Woody :
* signatures dans les paquets ;
* réessayer de supprimer les répertoires après la suppression des fichiers
de configuration ;
* support de Enhances dans dselect, verifier si cela fonctionne dans dpkg ;
* enregistrement des actions ;
* intégrer suidmanager ;
* intégrer debconf
* autoriser des dessertes versionnées dans dpkg et dselect.
(Ces points sont globalement triés aléatoirement)
Il y a bien plus d'autres choses à faire. Certaines d'entre elles
pourront être implémentées à temps pour Woody, d'autres non. Si vous
voulez les voir entrer dans Woody, veuillez proposer un correctif,
sinon elles ne seront probablement pas incluses.
Wichert.
--=20
_________________________________________________________________
/ Signature généralement sans intérêt - ignorez-la sans crainte \\
| wichert@liacs.nl http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
--IS0zKkzwUGydFO0o
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjj44iMACgkQPLiSUC+jvC1IjQCeIfeHJRDciGkU3dM221gy2m4Y
7ZcAn2vM7CmWk/nIq8TS7bPgLu6T4hfl
=6CHF
-----END PGP SIGNATURE-----
--IS0zKkzwUGydFO0o--
</pre>
<hr>
<a name=3></a>
<pre>
De : Wichert Akkerman <wichert@mors.wiggy.net>
Date : Sam 15 avr. 2000 20 h 50 ' 45 " -0400
À : debian-devel@lists.debian.org, debian-policy@lists.debian.org
Sujet : Registre de documentation
J'ai un peu réfléchi à comment la documentation est actuellement
enregistrée dans Debian, et il semble que nous le faisons mal. Pour
l'instant, il y a quelques façons d'enregistrer la documentation :
* appeler install-info ;
* utiliser un modèle doc-base et appeler install-docs ;
* mettre un fichier .dhelp dans le répertoire de documentation.
Je pense que nous devrions utiliser une seule méthode pour enregistrer
la documentation, et l'utiliser pour tous les paquets. Le registre
actuel de doc-base semble être une bonne méthode pour le faire. Il y a
cependant quelques problèmes :
* la manière de gérer les frontaux comme dhelp et dwww ne fonctionne pas,
et il faut que cela fasse quelque chose qui ressemble plus à ce que
update-menus fait ;
* cela ne gère pas les traductions.
Je pense que nous devrions faire quelque chose comme cela :
* tous les paquets enregistrent la documentation dans un fichier
d'enregistrement ajouté au répertoire /usr/share/doc-registry/ ;
* le fichier d'enregistrement liste le titre, l'auteur, le résumé et
les différents formats dans lesquels le document est disponible. Il
peut lister cela pour différentes langues, si cela est nécessaire ;
* les paquets appellent un outil appelé update-docs à partir de postinst
et postrm ;
* les paquets qui implémentent un frontal pour les documentations peuvent
ajouter une méthode de documentation dans le répertoire /etc/doc-methods/.
Pour le format du fichier d'enregistrement, XML semble être une bonne
stratégie. En utilisant la balise LANG, nous pouvons facilement supporter
différentes langues. Il y a de bons outils de traitement du XML pour
tous les langages de scripts et la plupart des autres langages. Cela
ressemblerait alors à :
<doc>
<id>bzip2</id>
<author>
<name>Julian Seward</name>
<email>jseward@acm.org</email>
</author>
<title>bzip and libzip2: a program and library for data compression</title>
<title lang=FR>bzip et libzip2: programme et bibliothèque pour la compression
des données</title>
<section>apps/tools</section>
<format type=html>
<index>/usr/share/doc/libbz2/manul_toc.html</title>
<files>/usr/share/doc/libz2/manual_*.html</files>
</format>
<format type=postscript>
<index>/usr/share/doc/libbz2/manual.ps.gz</title>
</format>
<format type=postscript lang=FR>
<index>/usr/share/doc/libbz2/manual-fr.ps.gz</title>
</format>
<format type=texinfo>
<index>/usr/share/doc/libbz2/manual.texi.gz</title>
</format>
<format type=texinfo lang=FR>
<index>/usr/share/doc/libbz2/manual-fr.texi.gz</title>
</format>
</doc>
Wichert.
--
_________________________________________________________________
/ Signature généralement sans intérêt - ignorez-la sans crainte \\
| wichert@liacs.nl http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
</pre>
#use wml::debian::weeklynews::footer translator="Thomas Huriaux"
Attachment:
signature.asc
Description: Digital signature