Nouvelles hebdomadaires Debian - Courriel

Gnome d'octobre pour Debian :

-- Vincent Renardias <vincent@debian.org> Vendredi 5 novembre 1999 17 h 44 ' 03 " +0100 
À : debian-devel@lists.debian.org
Sujet : Raisonnement d'Adam Di Carlo (était Re : GEL REPLANIFIÉ)
De : Adam Di Carlo <adam@onshore.com>
Date : 8 nov. 1999 21 h 26 ' 14 " -0500

Ci-jointe se trouve une justification du report du gel que j'ai envoyée
au forum slashdot. C'est la première fois que j'ai posté à cet endroit,
mais j'ai très peur de devenir la personne la plus détestée de Debian.
Dans tous les cas, je la poste ici au cas où des personnes veulent la lire.

Veuillez juste me laisser faire une préface en disant que je suis d'accord
avec ceux qui disent qu'un gel reporté de deux mois avec un cycle d'un
mois (si nous le réussissons) est mieux qu'un gel de trois mois. Pour les
développeurs ici, j'espère que vous éviterez d'envoyer des paquets très
instables tant que Potato n'est pas publiée.

--
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>

Tous ceux qui observent Debian depuis plus d'un an savent que la période
de gel est une phase très importante du projet. Le gestionnaire de
publication, Richard Braakman, a déclaré son désir que la durée totale
du gel ne soit pas plus longue que trois ou quatre semaines.

La discussion que j'ai eue avec lui concernant l'état de préparation
des disquettes de démarrage, en particulier, n'était que pour s'assurer
qu'il a toutes les informations nécessaires pour faire de son rêve une
réalité. Toute la question est d'entrer dans le gel avec un système
d'installation composé de toutes les fonctionnalités et prêt en version
bêta. Sans cela, ce n'est pas possible. Pour ceux qui se souviennent du
gel de Slink, il y a eu un cycle d'environ 16 semaines (elle a été
gelée au milieu de novembre, avec une publication à la mi-mars),
qui a été plutôt stressant pour tout le monde. Notre objectif est que
le gel soit prévu sur un ensemble assez stable de paquets, ce qui
nous permet complètement de tester plus sainement l'installation à partir
de rien ainsi que les mises à niveau de Slink vers Potato

[Pour votre information, mon estimation actuelle est que nous aurons
des disquettes de démarrage complètes le premier décembre. Je peux l'affirmer
avec la conviction que le premier janvier 2000, nous aurons ce que
j'appelle des disquettes de démarrage « de qualité pour la publication »
(c'est-à-dire ayant été beaucoup testées, mais avec encore un peu de
documentation à faire).]

Laissez-moi juste aborder quelques autres points rapidement.

* La raison principale pour laquelle je veux plus de temps pour les
fonctionnalités des disquettes de démarrage est que je pense qu'elles
sont très importantes. Parcourons-les brièvement : un nouveau
mécanisme de sélection du profil et des métapaquets task, qui permet
de continuer à utiliser ces mécanismes même après l'installation ;
utilisation d'apt dans quasiment tous les cas [pour la récupération
des paquets ; oui, je sais qu'il y a des situations avec des serveurs
mandataires SOCKS et d'autres situations obscures où cela peut ne pas
être une réalité] ; un configurateur d'apt, avec la possibilité
de détecter automatiquement les CD officiels aux endroits
attendus ; la possibilité d'installer base2_2.tgz via http
et peut-être ftp ; ensemble des données réseaux pour bootp et dhcp
lorsque c'est disponible ; superviseur de l'installation du paquet X,
capable de détecter automatiquement le paquet correct du serveur X.
Je pense que ces avancées sont importantes. Même avec le report, j'espère
que nous aurons le temps de les implémenter.

* Ceux qui disent que nous ne gèlerons jamais racontent des bêtises.
Nous désirons fortement nous mettre à jour et rendre obsolète la
distribution Slink.

* En ce qui concerne Linux 2.4, non, nous n'envisageons pas de synchroniser
nos cycles de publications avec ceux de Linux, ce qui devrait être clair
pour tout le monde. Pour le meilleur ou pour le pire. En supposant que
Linux 2.4 est stable (2.2 n'était pas si bien que ça au niveau de la
stabilité lorsqu'il est sorti, AMHA) et sortent dans les prochaines semaines,
il est certain que je ne m'y lancerai pas. Actuellement, nous pensons
utiliser 2.2.13 (même si cela peut varier entre nos 5 architectures
différentes).

* Nous réalisons que les mécanismes actuels de gestion des publications
montrent les limites dues à l'élargissement du projet. Il y a deux approches
possibles pour ce problème : (a) faire plus de « publications intermédiaires »
du système stable, ce qui nécessite simplement une équipe plus importante
qu'actuellement pour s'occuper de la distribution stable après sa
publication ; (b) reconcevoir complètement la gestion des publications,
le candidat le plus probable pour cela étant la proposition de « dépôts
de paquets » -- je n'ai pas de lien sous la main.

* Même avec cela, je voudrais le répéter, Debian reste la seule distribution
ayant un système de mise à niveau robuste et mis à l'épreuve (que ce
soit pour les nouvelles publications, récupérer des paquets de la
distribution instable, ou quoi que ce soit d'autre).

* Tant que nous sommes dans le domaine des « excuses », je ne pense pas
que beaucoup réalisent ici la quantité d'efforts nécessaires pour
coordonner Debian en général (ou les disquettes de démarrage, pour ce
qui nous concerne). Ce travail se réalise en coulisse, et certains d'entre
vous interprètent la lenteur de résolution de cette question comme de
l'indifférence. Je peux vous assurer que nous ne sommes pas indifférents,
en particulier en ce qui concerne la fréquence des publications et la
qualité des disquettes de démarrage.

Date : Mar. 9 nov. 1999 07 h 23 ' 23 " +1100
De : Chris Leishman <masklin@debian.org>
À : debian-devel@lists.debian.org
Sujet : Gel partiel ?

OK,

Voici une autre réflexion (sûrement une qui est déjà ressortie - nous
aimons tourner en rond. Faites-le moi savoir si c'est le cas).

Le problème pour le moment est que personne ne veut du gel, car nous
ne savons pas combien de temps il va durer - et pendant ce temps, les
choses sont bloquées et vieillissent. Et pourquoi ne savons-nous pas
combien de temps nous allons geler ? Car quelques paquets « critiques
à publier » (comme les disquettes de démarrage) ne sont pas stables
et nous ne savons pas combien de temps il faudra avant qu'ils ne le
soient.

Cependant - AMHA si nous ne gelons pas, alors nous sommes dans la même
situation que la distribution instable - à tout moment il peut y avoir
une mise à jour qui va provoquer l'échec d'un nouveau paquet « critique
à publier ». Qui sait - dans un mois quand nous aurons des disquettes de
démarrage, des paquets neufs ou mis à jour (ou une nouvelle charte)
pourraient nous empêcher de geler pour les mêmes raisons...

C'est vraiment un casse-tête. Si nous gelons, alors les choses vont
se stabiliser, mais elles risquent de périmer. Si nous ne gelons pas,
les choses ne périmeront pas, mais elles risquent de ne pas se stabiliser
rapidement.

Que faire alors : Nous identifions les paquets qui sont considérés comme
« critiques à publier ». Cela inclurait les paquets comme les disquettes
de démarrage et la charte. Ensuite nous déclarons un _gel de ces
paquets_. Les mêmes règles que pour un gel normal s'appliquent - seules
les corrections de bogues sont permises pour ces paquets.

Cependant, les nouveaux envois peuvent continuer pendant que cette chose
se stabilise - tant qu'ils ne créent pas de problème avec les paquets
« critiques à publier ». S'ils en créent, alors les règles du gel
s'appliquent sur cet envoi (pas de nouveau code).

Nous gèlerons éventuellement la distribution complète pendant un court
moment, pour nettoyer les bogues dans les paquets non principaux. Nous
devrions nous imposer une discipline stricte pour cela, et globalement
dire que s'il y avait une version sans _nouveau code_ qui n'a pas
montré de problème, alors nous la gardons plutôt que de corriger des bogues.

OK... la conclusion de cette idée.... Cela _peut_ allonger la
période de gel, puisque nous en faisons en pratique 2. Mais la deuxième
phase (la phase qui peut introduire une stagnation) sera bien plus
courte qu'elle ne l'est dans notre situation actuelle.

Une autre conclusion serait que cela semble être une évidence, et il n'y
a pas besoin de le rendre officiel... mais j'ai toujours trouvé que
ces choses fonctionnent mieux quand elles sont obligatoires.

La dernière question restante est la faisabilité de ce concept...


Cordialement,

Chris

(Souhaitez-moi bonne chance pour mon examen de macroéconomie dans... oh !...
une heure et demie :))

--
----------------------------------------------------------------------
            Linux, car j'aimerais *y être* aujourd'hui
----------------------------------------------------------------------
Répondez avec le sujet « request key » pour la clé GPG publique.
Identifiant de clé : 0xB4E24219

À : debian-devel-announce@lists.debian.org
Cc : ftpmaster@debian.org
Répondre-à : ftpmaster@debian.org
Sujet : Nouveaux membre de l'équipe de maintenance de l'archive
De : James Troup <james@nocrew.org>
Date : 9 nov. 1999 00 h 41 ' 51 " +0000

[ Veuillez ne pas répondre à debian-devel-announce ]

Salut,

J'aimerais souhaiter publiquement la bienvenue à Gergely Madarasz et
Antti-Juhani Kaijanaho qui rejoignent Guy, Richard et moi en tant que
membres de l'équipe de maintenance de l'archive.

Même si nous n'avons initialement demandé qu'une seule personne pour
aider, nous avons décidé de prendre deux nouveaux membres en raison
du nombre de nouveaux paquets qui sont envoyés tous les jours.

Merci à tous ceux qui se sont gentiment portés volontaires pour aider.

- --
James

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.