Nouvelles hebdomadaires Debian - Courriel

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 que 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 Quality Assurance (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 beaucoup 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 (wishlist). 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

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 jour.
	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.

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 tourne 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.

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
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, 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 quotidiennes, 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 parties 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 passante 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.

Pour recevoir cette gazette chaque semaine dans votre boîte à lettres, abonnez-vous à la liste de diffusion debian-news pour la version anglaise ou à la liste de diffusion debian-news-french pour la version française.

Les dernières parutions de cette gazette sont disponibles.

Ce numéro de la Debian Weekly News a été édité par Joey Hess.
Il a été traduit par Thomas Huriaux.