Merci d'avance pour vos relectures. -- Thomas Huriaux
#use wml::debian::weeklynews::header PAGENAME="Courriel"
#use wml::debian::translation-check translation="1.5" maintainer="Thomas Huriaux"
<a name=1></a>
<pre>
Date : Dim. 28 mars 1999 21 h 48 ' 05 " +0200
De : Martin Schulze <joey@finlandia.Infodrom.North.DE>
À : Développement de Debian <debian-devel@lists.debian.org>
Cc : QA Debian <debian-qa@lists.debian.org>
Sujet : Réactiver l'assurance qualité de Debian
Salut,
[ J'envoie ce courriel à la liste de développement de Debian et à celle
de l'assurance qualité. Veuillez ne répondre <b>que</b> sur celle de
l'assurance qualité : <debian-qa@lists.debian.org> ]
Comme beaucoup d'entre vous le savent, l'assurance qualité de Debian a été
plutôt calme ces derniers temps.
Qu'est-ce que debian-qa et est-ce mangeable ?
QA signifie <i>Quality Assurance</i> (assurance qualité) et est destinée
à garder la qualité de la distribution la plus haute possible. Pour le
moment, il n'y a pas d'assurance qualité réelle pour Debian. Cela est
principalement dû au fait que les personnes qui ont lancé l'assurance
qualité se sont retrouvées débordées par d'autres choses importantes
(liées à Debian).
Avons-nous besoin d'assurance qualité ?
Avec le nombre croissant de développeurs travaillant pour Debian (plus
de 500 développeurs sont enregistrés pour le moment), l'assurance
qualité est devenue un besoin urgent. Il est très intéressant de voir,
puisque ce n'est généralement pas le cas, que la qualité de Debian est
toujours aussi haute. En général, les entreprises ayant plus de
500 développeurs simultanés... je ne veux même pas y penser...
Même si nous avons des règles strictes (la charte) qui définissent les
nécessités pour chaque paquet, il manque toujours un « département » qui
s'assure que tous les paquets sont empaquetés correctement et s'intègrent
proprement au système.
Pour être honnête, il y a toujours <b>beaucoup</b> de paquets qui
n'utilisent pas les utilitaires et l'intégration suggérés (fichiers
menu, fichiers dwww, fichiers doc-base, alternatives, champs de
suggestions et de recommandations convenables, priorités convenables, etc.)
Maintenant que quelques nouveaux responsables ont mentionné le travail
sur l'assurance qualité et ses dérivés dans leur candidature en tant
que nouveau responsable, j'aimerais inviter les gens à travailler sur
l'assurance qualité pour Debian. Cela ne s'adresse pas qu'aux développeurs
disposés à y travailler à plein temps, mais aussi aux personnes qui ne
peuvent que passer quelques heures pour Debian.
J'apprécierais si quelques personnes, à la fois nouveaux et anciens
développeurs, se portaient volontaires pour travailler sur l'assurance
qualité de Debian GNU. Veuillez regarder la liste suivante - incomplète -
des choses qui rentrent dans le domaine de compétence de l'équipe de
l'assurance qualité :
. vérifier les anciens bogues - et y travailler ;
. vérifier les paquets avec beaucoup de bogues - et y travailler ;
. vérifier si tous les paquets qui fournissent des programmes pour
l'utilisateur (graphiques ou pas) viennent avec les fichiers menu ;
- de tels paquets doivent appeler update-menus dans les scripts
qui suivent l'installation et qui précèdent le retrait ;
. vérifier si tous les paquets qui fournissent de la documentation
l'enregistrent pour dww, doc-base ou quoi que ce soit d'autre ;
. vérifier si les paquets sont conformes avec la charte ;
. ajouter de la documentation où cela est nécessaire - il y a beaucoup
d'endroits où il manque de la documentation ;
. détecter les paquets orphelins et s'en occuper ;
. vérifier si les paquets fonctionnent toujours - en particulier les
anciens ;
. vérifier si les champs de priorités, de recommandations, de suggestions
et de dépendances sont utilisés correctement ;
. vérifier si les paquets sont liés aux bibliothèques convenables,
peut-être vérifier s'ils fonctionneraient avec des nouvelles versions
stables (en particulier pour les programmes basés sur Gtk) ;
. suivre les nouvelles versions des logiciels et informer le responsable
si nécessaire.
Si vous trouvez des paquets qui manquent de soutien pour l'une des choses
mentionnées ci-dessus, l'action appropriée serait de soumettre un bogue
de souhait (<i>wishlist</i>). Le rapport de bogue doit donner la
documentation appropriée, ou mieux, inclure une description des
fonctionnalités manquantes et la marche à suivre pour les résoudre. Cela
serait mieux si le rapport inclut un correctif, un fichier menu, un
fichier avec la documentation...
Cordialement,
Joey
--
La bonne chose avec les standards est qu'ils sont si nombreux qu'on peut
les choisir.
-- Andrew S. Tanenbaum
Veuillez m'envoyer une copie de tous les courriels que vous envoyez en
réponse sur les listes de diffusion.
--
Pour vous désinscrire, envoyez un courriel à
debian-qa-request@lists.debian.org avec comme sujet « unsubscribe ».
Des problèmes ? Contactez listmaster@lists.debian.org
</pre>
<hr>
<a name=2></a>
<pre>
Date : Dim. 28 mars 1999 21 h 55 ' 16 " +0200
De : Martin Schulze <joey@finlandia.Infodrom.North.DE>
À : Debian Policy <debian-policy@lists.debian.org>
Sujet : Responsabilité, responsables absents ou disparus (AQ)
J'essaie de faire revivre l'assurance qualité de Debian. Avec le nombre
croissant des responsables qui montrent de l'intérêt pour l'assurance
qualité en général de Debian, cela semble très utile que l'un des
« anciens » responsables montre la direction.
Cependant, si cela marche et que nous avons une équipe d'assurance qualité
en fonction, nous devons définir les permissions d'envoi de paquets
de l'équipe. Elle doit pouvoir travailler sur les paquets apparemment
orphelins même si le responsable n'a pas rendu orphelin le paquet.
La suite est extraite d'un texte que Vincent Renardias a écrit en
février 1997. Je ne le modifie pas, afin de pouvoir en discuter
convenablement. Veuillez garder à l'esprit que certaines parties peuvent
être maintenant dépassées.
Cordialement,
Joey
---------------------------------------------------------------------------
* Politique d'envoi de correction de bogues :
* paquets maintenus :
Envoyez les correctifs au responsable, et, éventuellement,
envoyez la version corrigée s'il n'y a pas de réponse
(voyez les « délais d'envoi » ci-dessous).
* paquets orphelins :
les envois de correction de bogues peuvent être faits à
tout moment par les membres du groupe d'assurance qualité de
Debian.
Lancer un appel à responsable sur debian-devel.
Si personne n'est trouvé après 1 mois :
- pour les paquets importants (c'est-à-dire
« nécessaires » ou « standards ») :
Le paquet sera maintenu par le groupe
d'assurance qualité de Debian jusqu'à ce qu'un
responsable soit trouvé.
- pour les paquets non importants :
Si personne ne se porte volontaire pour s'en
occuper au bout de ce délai, ils seront
envoyés dans la section « project/orphaned ».
* Délais pour les envois d'appropriation :
Lorsqu'un correctif est envoyé par le groupe d'assurance qualité de
Debian à un responsable, combien de temps le groupe doit-il attendre
avant d'envoyer le paquet si le responsable ne l'envoie pas lui-même ?
Délais :
- correction critique de sécurité : 2 jours ;
- correction de sécurité : 7 jours ;
- correction de bogue : 30 jours ;
(Corrige un bogue signalé dans le système de suivi des bogues
ou RFE.)
- correction marginale : 45 jours ;
(erreur dans une page de manuel, fichier core dans le
paquet source...) ;
NB : « les corrections marginales » sont envoyées uniquement
dans la version « instable » (pas dans la « stable » ou la
« gelée »).
Les délais ci-dessus sont réduits par un facteur 2 le mois qui
précède un gel.
Pendant un gel : le délai pour les corrections de sécurité (celles
annoncées sur <security@debian.org>) : 1 jours.
Autres corrections : 1 semaine.
[Ces délais sont-ils trop courts ou trop longs ?]
Les membres du groupe d'assurance qualité envoyant des
corrections de bogue devront non seulement respecter ces délais, mais
également annoncer leur intention d'envoyer sur <debian-qa> avec
une copie au responsable, au moins deux jours (ou 1 jour pendant
un gel) avant de faire l'envoi, en précisant quelle version
du paquet ils vont envoyer, ainsi que les numéros de série des bogues
corrigés par l'envoi.
Le champ « Maintainer » de ces paquets envoyés resteront
inchangés.
Cependant, si les membres du groupe d'assurance qualité
font trois envois de corrections de bogue consécutifs sans aucune
action du responsable du paquet, alors le champ « Maintainer » sera
mis à « Orphaned Package <debian-qa@lists.debian.org> », et le
paquet sera considéré orphelin (cela sera annoncé sur
<debian-devel>).
- travail sur les distributions stable et instable :
--
La bonne chose avec les standards est qu'ils sont si nombreux qu'on peut
les choisir.
-- Andrew S. Tanenbaum
Veuillez toujours m'envoyer une copie lorsque vous me répondez sur une
liste de diffusion.
--
Pour vous désinscrire, envoyez un courriel à
debian-policy-request@lists.debian.org avec comme sujet « unsubscribe ».
Des problèmes ? Contactez listmaster@lists.debian.org.
</pre>
<hr>
<a name=3></a>
<pre>
Date : Dim. 28 mars 1999 1999 18 h 14 ' 36 " -0700 (MST)
De : Ward Deng <wdeng@KachinaTech.COM>
À : debian-ultralinux@KachinaTech.COM, debian-ultralinux@lists.debian.org,
debian-sparc@lists.debian.org, debian-devel@lists.debian.org
Sujet : xia01 est dorénavant débianisée pour le développement de UltraLinux !
Chers développeurs Debian,
J'ai passé beaucoup de temps cette semaine à mettre à jour vers Debian 2.1
(Slink) notre xia01, un système UltraSPARC. Cela s'est passé sans problème.
Bravo à tous ceux qui ont contribué. L'image TFTP est identique à celle
utilisée pour installer la Debian 2.1 32 bits sur xia03, une station
SPARC LX. Nous avons assez d'espace pour héberger un miroir Debian presque
complet pour les architectures i386 et SPARC, en incluant incoming/.
Le cron lance rsync tous les jours.
Maintenant, parmi les trois systèmes (xia01-3), deux (xia01-2) tournent
sous Debian en natif. La dernière xia03 tournent toujours sous
UltraPenguin 1.09. Je peux soit le convertir en Debian, soit le mettre à
niveau vers le dernier UP 1.19 et le prendre comme système de référence.
Faites-moi savoir ce que vous en pensez.
Encore une fois, ces trois systèmes sont accessibles publiquement à tous
les développeurs Debian et à tous ceux qui sont intéressés pour aider le
projet UltraLinux de Debian. Je vous créerai un compte si vous le demandez.
J'espère évidemment que beaucoup de développeurs vont s'impliquer.
Je testerai cette distribution avec plus de configurations matérielles
et la documenterai en HTML au cours de la semaine prochaine. Franchement,
c''est facile et léger à installer.
Voici le dernier message d'accueil :
Bienvenu au projet Debian-UltraLinux !
-----------------------------------------------------------------------------
xia01 : UltraSPARC I-170, 64 Mo, 3.5 Go (système+/home2), 13 Go (/Debian)
Debian 2.1 (Slink) noyau 2.2.1 (mis à jour le 27 mars 99)
xia02 : SPARCstation LX, 64 Mo, 1.08 Go, Debian 2.1 (Slink)
noyau 2.2.1 (mis à jour le 18 mars 99)
xia03 : Sun Ultra30, UltraSPARC II-250, 128 Mo, 4.2 Go (système et données)
UltraPenguin-1.0.9, noyau 2.1.125
Remarque : xia01 et xia02 ont été mises à disposition par Kachina
Technologies, Inc. et xia03 est un système prêté par Sun Microsystems, Inc.
-----------------------------------------------------------------------------
Cordialement,
--ward
--
Pour vous désinscrire, envoyez un courriel à
debian-sparc-request@lists.debian.org avec comme sujet « unsubscribe ».
Des problèmes ? Contactez listmaster@lists.debian.org.
</pre>
<hr>
<a name=4></a>
<pre>
Date : Lun. 29 mars 1999 02 h 16 ' 58 " -0600 (CST)
De : Adam Heath <doogie@debian.org>
À : Debian Devel List <debian-devel@lists.debian.org>
Sujet : changement de l'heure de lancement de dinstall sur master
Ceci est devenu un sujet brûlant, ce qui n'était pas mon intention. Je
n'ai jamais voulu chauffer personne. Si j'ai marché sur les pieds de
quelqu'un, j'en suis vraiment désolé.
Maintenant, quelques clarifications.
Mon courriel initial était le point de vue du fournisseur de service. Novare
fournit de la bande passante au projet Debian. Nous hébergeons également
plusieurs machines pour Debian. Master, murphy (lists), faure, albert (les
deux dernières sont des Alpha). Il faut ajouter à la liste les nouvelles
qui ne sont pas encore en ligne, à savoir une Sparc et une nouvelle machine
donnée par va.
Novare participe aux frais en se basant sur la quantité actuelle de données
est transférée chaque mois, jusqu'à un certain niveau. Après cela, nous
devons payer le surplus. Nous ne nous sommes pas encore approchés de cette
limite, donc nous n'avons pas encore eu de frais supplémentaires. De toute
façon, si cela arrivait, nous les répartirions entre nos consommateurs,
donc ce point est tout à fait discutable.
Notre fournisseur amont, cependant, est facturé en fonction de la quantité
de bande passante utilisée en se basant sur le pourcentage de ce qui est
disponible. En mettant à jour le miroir aux heures de pointe (entre 15 h
et 17 h en heure locale), nous fâchons probablement notre fournisseur amont.
Maintenant, vous pourriez dire que nous ne devrions pas nous soucier de
notre fournisseur amont, mais, si nous pouvons l'aider en déplaçant l'heure
de mise à jour du miroir, je ne vois pas quels problèmes cela poserait.
Jason Gunthorpe, chef des administrateurs de Debian, a configuré mrtg sur
tous les serveurs principaux de Debian. Cela inclut master. Pour voir les
statistiques, allez sur http://master.debian.org/mrtg/. Veuillez noter que
les nombres se sont réduits au cours de cette année. Cela est probablement
dû au fait que l'équipe d'administration a interdit aux personnes de faire
des miroirs personnels de master. En ayant une impulsion du miroir pour
contacter les miroirs de première catégorie, qui contactent ensuite master
et récupèrent les mises à jour quotidienne, cela a permis aux personnes
qui ont des miroirs personnels de répartir leur chargement.
Les statistiques à l'adresse ci-dessus incluent également une représentation
du trafic créée par Novare. Ce traffic ne sort pas par notre FAI, donc il
n'est pas inclu dans les chiffres qu'il calcule. Une partie de ce trafic
de Novare inclut un miroir local complet de Debian, qui est utilisé par les
Alpha (et bientôt par les Sparc quand elles seront en ligne), ainsi que par
le reste de Novare. Master et murphy ne sont plus physiquement situées chez
Novare. Elles se trouvent dans un espace coloué qui se trouve à environ
25 kilomètres.
Je suis un développeur (voyez l'adresse électronique ci-dessus) et je
travaille également chez Novare, qui héberge de l'équipement pour Debian.
J'ai donc une approche unique sur beaucoup de sujets concernant ce
problème. Je connais une partie de ce que master fait actuellement et
ce qu'elle est capable de faire. Je connais également l'approche en
tant que donateur. Cela peut parfois me faire prendre une position
maladroite. Ean Schuessler, qui est coparticipant à Debian, et qui est mon
chef, m'a très souvent demandé mon opinion sur les affaires internes de
Debian, en voyant comment en à peine plus d'un an je l'ai dépassé en
quantité de « travail pour Debian ». Cependant, il a été affilié à
Debian, en tant que personne extérieure en quelque sorte, bien avant
que je connaisse l'existence de celle-ci.
Je vais citer des partie de mon courriel en les commentant, pour essayer
d'expliquer et de clarifier ce que je veux dire.
Mon courriel original sera précédé de « > », et mes ajouts seront
encadrés par « - ». Tout commentaire additionnel suivra les ajouts.
----
> L'heure actuelle de lancement de dinstall, à savoir 13 h 53 CST
> (local) soit 19 h 53 UTC, provoque l'impulsion du miroir entre
> 15 h 30 (21 h 30) et 17 h 30 (23 h 30). C'est pendant les heures de
> pointe. Ce n'est pas bon, et cela doit être changé.
-
Dinstall se lance actuellement à 13 h 53 (19 h 53). Dinstall s'arrête en
général entre 15 h (21 h) et 17 h (23 h), avec l'impulsion du miroir suivant
immédiatement. L'impulsion du miroir contacte tous les miroirs de première
catégorie, c'est-à-dire les miroirs qui se mettent à jour directement
à partir de master. Il y en a actuellement 9, divisé en 2 groupes,
séparés de 10 minutes. 3 d'entre eux sont des miroirs non-US (merci à
Jason pour l'information). La mise à jour quotidienne pour un miroir complet
est en moyenne de 50 mégas.
Les heures de pointe sont localement de 15 h (21 h) à 19 h (01 h). Cela
correspond aux heures où les enfants sortent de l'école, rentrent à la
maison et se connectent, ainsi que lorsque les parents sortent du travail et
font la même chose.
Avoir la mise à jour massive pendant l'heure de pointe signifie qu'elle
dure plus longtemps, puisqu'elle doit se battre avec tous les autres
comptes de notre FAI. Celui-ci est facturé également différemment pour
sa bande passante : non pas en fonction de la quantité de données qu'il
envoie pendant un mois, mais par la quantité de bande passant qu'il
utilise sur une période beaucoup plus petite. S'il y a une pointe pendant
la journée, il peut voir sa facture augmenter. Il n'aime évidemment pas
cela. Il a remarqué que ce pic important était de notre faute (Novare),
et a cherché à savoir pourquoi cela se passait au milieu de la journée.
-
> Je veux déplacer l'heure à laquelle dinstall se lance, et je pense
> la fixer à minuit (0 h, 6 h UTC). Cela provoquerait l'impulsion du
> miroir entre 1 h 30 (7 h 30) et 3 h 30 (9 h 30).
-
Nous (Novare) désirerions que l'heure de lancement de dinstall soit changée.
Minuit (6 h) semble être le bon moment. Cela mettrait l'impulsion du
miroir entre 1 h 00 (7 h 00) et 3 h (7 h).
-
Il n'y a pas grand chose d'autre à dire.
> Ce courriel n'est pas une discussion pour décider s'il faut changer ou
> pas l'heure de lancement de dinstall. Il le faut dans tous les cas. Ce
> courriel est pour discuter des alternatives possibles.
Je ne vais pas le réexpliquer, car je trouve que c'est un peu difficile de
le faire. Je vais juste le commenter.
Je ne suis pas au courant des éventuels problèmes techniques qui suivraient
un déplacement de l'heure de lancement de dinstall. J'ai un peu l'impression
que l'heure actuelle a été prise « un petit peu au hasard ». Je ne m'attends
donc à aucune opposition pour la déplacer. Je veux lancer une discussion
pour chercher la meilleure heure possible, tant que ce n'est pas durant
les heures de pointe locales.
> Y a-t-il eu une discussion initiale sur (irc.debian.org (aussi
> irc.openprojects.net) #debian). Pourquoi ne pouvons nous pas lancer
> dinstall à plusieurs moments de la journée, et n'avoir qu'une seule
> impulsion du miroir ? Des parties de dinstall peuvent-elles être
> lancées séparément ?
Encore une fois, je ne vois pas le besoin de réexpliquer.
Cela a été lancé comme une sorte de pensée venue plus tard. Cela n'est pas
vraiment en accord avec le ton du reste du courriel, et devrait
probablement être transféré sur la configuration faite par
« debian-dinstall@lists.debian.org » (joey ?).
Ensuite vient une courte réponse au courriel d'origine, qui explique quelque
chose que je n'ai pas abordé.
----
> Je suis désolé, j'ai oublié de dire que cela n'arrivera pas aujourd'hui,
> ni demain. Je suis absent en fin de semaine. Disons pour le samedi
> 3 avril.
C'était pour retirer les craintes que des personnes comme moi fassent
quelque chose d'inattendu. Le moment auquel le changement d'heure du
lancement de dinstall sera effectif est négociable. Je voulais que cela
soit clair que rien ne se passerait soudainement.
----
OK. Fait. Ouf. J'ai trop tapé (je dois parler à Ean et prendre des cours
pour exercer mes doigts).
J'espère que je n'ai pas laissé l'histoire sans fin, et que cela retire
les quelques craintes que j'ai vues sur ce sujet.
Adam, qui essaie seulement de faire son travail
--
Pour vous désinscrire, envoyez un courriel à
debian-devel-request@lists.debian.org avec comme sujet « unsubscribe ».
Des problèmes ? Contactez listmaster@lists.debian.org.
</pre>
#use wml::debian::weeklynews::footer translator="Thomas Huriaux"
Attachment:
pgp8FTjN4nTst.pgp
Description: PGP signature