[Linux-bruxelles] Debian or not debian

Mer 25 Aou 17:08:55 CEST 2004

Ca c'est du dépilage... :-) Bonne rentrée !

On Wed, Aug 25, 2004 at 02:09:11PM +0200, Jerome Warnier wrote:

> On Thu, 2004-06-10 at 00:58, Hervé Eychenne wrote:
> > On Wed, Jun 09, 2004 at 11:00:38PM +0200, Frederic Peters wrote:
> > 
> > > Hervé Eychenne écrivait :
> > 
> > > > > Tant de chose ?  Une vingtaine de paquets ?  Ça va.
> > 
> > > > Mon Dieu, c'est encore bien pire que je ne croyais :
> > > > $ apt-cache dumpavail | sed -n 's/^Maintainer:.*</</p' | sort | uniq -c
> > > >   | sort -n | less
> > 
> > > > Edifiant.
> > 
> > > De ces infos, comment arrives-tu à connaître le temps nécessaire pour
> > > un paquet / le temps disponible par le développeur pour Debian ?
> > 
> > Je n'ai pas besoin de faire de comptes d'apothicaire pour voir
> > qu'environ 194 mainteneurs (sur 1299) s'occupent de plus de 20
> > packages chacun. Et que 8527 packages sur 14146 sont donc maintenus par
> > quelqu'un qui a au moins 20 packages en charge.

> C'est toujours comme ça. Sauf que tu nous montres que Debian fait bien
> mieux que ce que je peux constater dans d'autres domaines avec des
> bénévoles: je vois rarement plus de 10% des gens s'occuper efficacement
> de quelque chose, or ici tu nous montres qu'environ 1/6 des développeurs
> Debian est actif. Je trouve cela bien.

Comme on peut très bien faire des paquets Debian non officiels dans son
coin, on peut supposer ("exiger" ?) qu'un enregistrement en tant que
mainteneur Debian officiel implique un engagement, et donc une
"garantie" d'activité correcte ?
Je pense donc que le taux de mainteneurs Debian actifs devrait donc
être proche de 100%, hors coups de bourre transitoires et bien sûr
non-évolution du logiciel upstream.
En cas de difficultés même temporaires, tout mainteneur devrait
demander de l'aide en vue d'une co-maintenance, et si les difficultés se
prolongent, elles doivent mener à un "orphaning" du paquet.

De toute manière, tu as (à dessein, je suppose) retourné mon
raisonnement pour faire une comparaison avec une association du type
BxLUG (c'est vrai que c'est la problématique à laquelle ont à faire
face toutes les associations, mais une adhésion peut dans ce cas se
réduire à de la sympathie ou un simple apport de cotisation).
Je rappelle que mon propos initial était qu'un nombre réduit de gens
s'occupe de bien trop de paquets Debian importants, avec tout ce que
cela suppose (surcharge de travail, retards, laxisme, erreurs, absence
de vérification par les pairs, absence de partage des responsabilités,
etc.).

> > Je sais que tu vas essayer de m'entraîner sur le terrain de la
> > constestation des chiffres et des méthodes de calcul, mais je n'ai pas
> > l'intention de rentrer dedans. Il est pour moi évident que l'on ne
> > peut pas gérer plus de 20 packages correctement.
> > 
> > Il est d'ailleurs intéressant de mettre en parallèle le nombre de
> > packages maintenus par une personne donnée et le nombre de bugs
> > release-critical associé à ce mainteneur.

> À mon avis, les bugs RC si longtemps avant une release n'ont pas de
> signification importante.

Alors le terme Release Critical est mal choisi... Il faudrait
introduire un autre terme, plus neutre, genre non-working.

> > nbr_RC : nombre de bugs release-critical (empêchant le passage de
> >   sarge en stable) détenu par ce mainteneur

> Il n'y a pas que cela, il y a aussi d-i.

Oh, il y en avait 2 ou 3 autres encore, oui.

> > nbr_maintenus : nombre de paquets gérés par ce mainteneur
> > 
> >  adresse          nbr_RC  nbr_maintenus
> > 
> > coven at debian.org    14    40
> > kitame at debian.org   10   108
> > gibreel at debian.org   9   108
> > rkrusty at debian.org   7    32
> > mhatta at debian.org    6    77
> > dres at debian.org      6    25
> > turbo at debian.org     5    96
> > gopal at debian.org     5    21
> > foka at debian.org      5    64
> > tv at debian.org        4    38

> Il faut surtout savoir que dans ta liste, plusieurs autorisent
> explicitement les NMU sur leurs packages, et n'en sont pas moins bons
> pour traiter les problèmes qu'ils peuvent.

Je n'ai pas dit le contraire, je dis juste qu'il n'est pas possible
que tout ces gens soient des Alan Cox made in Debian.

> > > > > De plus en plus de paquets incluent des fichiers .watch qui permettent
> > > > > justement ça.
> > 
> > > > De quoi s'agit-il exactement (techniquement) ?
> > > > $ cd /var/cache/apt/archives ; for i in *.deb ; do dpkg -c $i ; done | fgrep .watch
> > > > ne donne rien, et un moteur de recherche Web non plus.
> > 
> > > Le mien me donne des infos pertinentes.  debian watch files
> > 
> > Ok, c'est bien que ce mécanisme existe. Mais :
> > - tout bon mainteneur d'un paquet devrait être abonné à la
> >   mailing-list de l'application qu'il package. Il ne devrait donc en théorie
> >   pas avoir besoin de fichiers watch.

> Les fichiers watch ne servent pas qu'au mainteneur du package. Ils
> servent aussi pour tous les autres, et aussi pour faire des stats et
> tenter d'améliorer la transparence et la qualité de Debian. Faire cela
> manuellement n'aurait aucun sens.
> De plus, il existe plein de projets qui n'ont pas de ml, ni d'annonces
> ni de quoique ce soit.

Certes.

> > - il devrait y avoir un repository libre recensant les projets libres
> >   et leurs différentes versions. Ne me parlez pas de freshmeat, ce
> >   n'est pas libre. Conséquence : leur peur de voir leur base de
> >   données pillée et l'absence d'accès au code source de leur backend
> >   fait qu'il est en pratique impossible de programmer des outils
> >   fiables permettant de faire ce qu'il faudrait faire, à savoir une
> >   library de fonctions d'accès à la base et l'outil en ligne de
> >   commande (et X, pourquoi pas) permettant de :
> >   - mettre à jour automatiquement la base pour le développeur (avec
> >     signature)
> >   - faire des requêtes dans la base

> Ça pourrait être une bonne idée. Mais alors, pourquoi ne pas utiliser
> les fichiers watch de Debian comme base pour composer cela?

Parce que :
- ce repository du libre dépasse le cadre de Debian
- la mise à jour des versions n'est qu'une part des informations de la
  base de données
- plutôt que d'essayer de traquer les nouvelles versions
  automatiquement (ce qu'il n'est pas possible de faire en totalité
  de manière fiable et universelle), cette mise à jour de la base
  devrait d'abord se faire au niveau des mainteneurs upstream
  eux-mêmes, via un fichier simple et une commande publish qui ferait
  tout ce qu'il y a à faire. Le tout étant complété par des anonymes,
  avec modération éventuelle.
- il existe déjà 2 autres sources d'information intéressantes, à
  savoir freshmeat et le GNU software directory.

> > Mais la question n'est même pas là. La question initiale était en
> > substance : un mainteneur ne devrait pas avoir besoin d'un outil
> > automatique pour être informé de la sortie d'une nouvelle version, car
> > il est censé suivre le logiciel un peu au jour le jour, sinon c'est
> > bien moins sérieux. On considère donc que cela devrait être le cas dès
> > aujourd'hui. Comment, donc, expliquer de tels retard de packaging pour
> > bon nombre applications ? (je ne parle pas des applications difficiles
> > à packager, comme kde, X, ou autres)

> Tu es informaticien (et développeur), et tu trouves que le mainteneur ne
> devrait pas avoir trop d'outils automatiques pour l'aider???

Je pense qu'un mainteneur Debian doit s'intéresser au développement de
l'upstream et le suivre de manière rapprochée. Quand tel est le cas,
passer à côté d'une release est inenvisageable, et les fichiers watch
ne servent à rien dans ce cadre (uniquement).
Mais je ne conteste pas l'intérêt des fichiers watch pour les
"corner-cases", et les stats, etc. (tout ce que tu as mentionné plus
haut).

> [..]

> > Je n'ai pas le coeur de chercher des exemples actuels, mais ce qui me
> > vient à l'esprit en vrac à cette heure sans recherche aucune :
> > - kde : chaque release de KDE est suivie quasiment immdiatement de la
> >   mise à disposition de paquets Debian sur le site de KDE, et il faut
> >   plusieurs mois aux mainteneurs Debian s'occupant de KDE pour arriver
> >   à sortir un paquet "Debian officiel".

> Parce que les développeurs Upstream de KDE ne sont pas assez
> perfectionnistes: ils ne testent pas forcément avec la version de GCC
> dans Debian, ni certainement sur la moitié des plateformes supportées
> par Debian. De plus, ils ne se soucient pas de l'intégration avec
> d'autres applications ou environnements (comme GNOME par exemple).

Oui... hélas...

> > - discover : il est resté pendant des mois sans la moindre activité,
> >   alors qu'il aurait dû constituer à mon sens l'essentiel des efforts de
> >   Debian ! (sachant son retard sans l'auto-configuration par rapport à
> >   tant d'autres distributions)

> Discover2 était en grands travaux, et donc plus beaucoup de développeurs
> ne travaillaient sur la version 1.

Cela ne me semble pas justifier le fait qu'aucun de ces mainteneurs
n'ait fournit pendant plusieurs mois les 20mn de travail à peine sur
la version 1 Debian qui auraient corrigé des bugs sérieux, et pour
lesquels il existait déjà un patch facilement applicable.

> > - http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=tag&data=fixed-upstream&archive=no
> >   et regarder l'ancienneté des bugs corrigés en upstream, mais pas
> >   dans le paquet Debian correspondant. Il y a en tout de même
> >   beaucoup, et ils sont souvent très vieux.

> > > > > Non.  Peut-être parce que l'opinion qu'exclure quelqu'un est un acte
> > > > > grave est partagée par la plupart des développeurs Debian ?

> > > > <troll>"Tout le monde sait qu'untel est notoirement inefficace, mais il est
> > > > indéboulonable". On se croirait dans la fonction publique...</troll>

> > > Je ne vois pas qui est notoirement inefficace.

> > Redite :
> > - certains développeurs qui ont bien trop de paquets à gérer et/ou qui
> >   les gèrent mal

> On n'est pas forcément d'accord.

Ok, tous les mainteneurs Debian sont au même niveau, et... quasi-parfaits.
Au temps pour moi. ;-)

> > - incapacité de Debian à produire une distribution stable à intervalle
> >   raisonnable

> Il y a plusieurs projets intéressants pour contourner ce problème, en
> voici une: "Componentized Linux" de Progeny.

Mais pourquoi donc faut-il toujours un projet extérieur à Debian pour
résoudre les problèmes qui devraient être résolus dans la Debian
elle-même ?

> [..]

> > > > > Mais l'utilisateur de Debian qui se retrouve avec une applic non
> > > > > intégrée dans les menus parce que "monsieur le développeur trouve que
> > > > > les menus, c'est nul"; qu'en fait-on ?

> > > > Qu'en fait-on de qui ? Du développeur ? Eh bien son programme est
> > > > moins bien intégré dans Debian, ou alors Debian peut toujours rajouter
> > > > un mécanisme supplémentaire pour qu'il soit intégré correctement.
> > > > Il y aurait des développeurs grincheux, mais je pense que ça serait
> > > > marginal, et tant pis pour eux.

> > > Voilà, "Debian peut toujours rajouter".  C'est ce que Debian fait.

> > Oui. Et je dis que Debian le fait trop souvent, car l'appli ne donne pas
> > spontanément l'infrastructure nécessaire, alors qu'elle le devrait.

> D'accord, mais changer les habitudes de tous les développeurs de
> logiciels libres est à mon avis encore un cran au-dessus d'améliorer
> Debian, point de vue réalisation.

L'un n'exclut pas l'autre...

> [..]

> > > > Bref, ton argument n'est pas valable (car a contrario tu pourrais tout aussi
> > > > bien dire qu'à ce compte-là tu n'aurais nulle envie d'installer ar
> > > > pour pouvoir accéder au contenu d'un .deb).
> > 
> > > ar est standard, je l'ai vu installé sur des systèmes qui étaient loin
> > > d'être des Unix libres...

> > Redite/résumé :
> > Si tu veux voir à la main le contenu d'un package (ce qu'une partie
> > infîme des utilisateurs du paquet est censée faire), tu installes le
> > logiciel qui te le permet, et ce logiciel devrait être l'outil natif de
> > gestion des packages (dpkg ou rpm).

> J'ai déjà eu l'utilité d'un fichier de configuration contenu dans un
> .deb sur une Sparc avec Solaris. Ça te va comme exemple?

Bah, rarissîme, et dans ce cas, rien ne devrait empêcher la
compilation de l'outil de gestion de paquet sous Solaris.

 Hervé

-- 
 _
(°=  Hervé Eychenne
//)  Homepage:          http://www.eychenne.org/
v_/_ WallFire project:  http://www.wallfire.org/