[Linux-bruxelles] Debian or not debian

[Hervé Eychenne]

On Thu, Jun 10, 2004 at 08:44:18AM +0200, Frederic Peters wrote:

> Hervé Eychenne écrivait :

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

> Ce qui ne me pose aucun problème.  La relation "beaucoup de paquet" =>
> "moins de temps par paquet" étant à mes yeux trop simpliste.

Je suis d'accord que c'est plus compliqué que ça. De plus, il ne faut
considérer que les paquets sources, et pas les paquets binaires comme
je l'ai fait. Mais les proportions restent comparables.
Je veux bien croire qu'il y ait chez Debian quelques surhommes, mais
il ne peut pas y en avoir autant. :-)
Bref, la discussion ne permettra pas de trancher sur des critères
objectifs, restons-en là. :-)

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

> Mais si, on peut tout à fait.  3000 paquets dans une Red Hat, ça
> signifie qu'il leur faudrait 150 mainteneurs ?  Bien sûr que non,
> c'est absurde.

Je connais si peu la façon dont les paquets arrivent dans une Redhat
que je ne peux pas vraiment argumenter sur ce point.
Il me semble malgré tout que les développeurs upstream fournissent
souvent déjà eux-mêmes un paquet RPM (plus souvent qu'un .deb,
d'après mon sentiment personnel).
Je pense que c'est sûrement parce qu'il n'y a qu'un seul fichier
(.spec) et qu'il paraît plus simple (sans doute parce que moins
puissant). Bref, je pense que les packageurs Redhat partent souvent
déjà d'un existant, ce qui facilite beaucoup les choses. C'est tout ce
que je peux dire.

> > 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.
> > 
> > nbr_RC : nombre de bugs release-critical (empêchant le passage de
> >   sarge en stable) détenu par ce mainteneur

> À nuancer parce que tu as dans les statistiques aussi des bugs ne
> s'appliquant qu'à Woody ou Sid (et n'influançant ainsi pas la sortie
> de Sarge).  Et ce ne sont de toute façon pas les bugs RC qui empêchnt
> la sortie de Sarge...

Tu veux dire que c'est plutôt l'installeur, c'est ça ? Sans doute,
pour l'instant. Et après, ça sera les problèmes de licence de la
documentation et les problèmes d'inclusion de firmware dans les
paquets noyau. Et quoi d'autre après ? Je commence à penser que ça
ne finira jamais.
Je ne suis pas en train de dire que ces préoccupations ne sont pas
légimites, mais au final, tout ça va paralyser la sortie de la
nouvelle Debian stable pendant encore au moins 6 mois.
On en revient à ce que je disais en guise de caricature : "never finished,
never released".
Et donc tous les problèmes qui font que Debian devient difficile à
utiliser (tout court), que ce soit en entreprise ou chez le particulier
(en gros, problèmes que j'ai déjà cité : woody bien trop ancien,
sarge pas assez sûr ou trop pénible à maintenir).

> > 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
> > 
> > Là encore, très édifiant.
> > J'attends avec impatience de voir à quel détail tu vas t'accrocher
> > pour démontrer que j'ai tort d'affirmer que bon nombre de
> > développeurs gèrent bien trop de paquets à la fois.

> Je viens de supprimer trois paragraphes, ils "s'accrochaient à des
> détails", ils tentaient de minimiser l'importance de certains bugs
> FTBFS, etc.  Mais ça m'obligeait à lire les rapports, ça prenait du
> temps, ça allait être considérer comme "des détails".

Bien vu. :-)

> Alors qu'il était si simple de montrer qu'il était possible de gérer
> un nombre important de paquet sans avoir un seul bug RC:

>  160 <bab at debian.org>
>  147 <sam+deb at zoy.org>
>  129 <akira at debian.org>
>  120 <joerg at debian.org>
>  114 <grendel at debian.org>
>  104 <edd at debian.org>
>  102 <herbert at debian.org>
>   93 <jaldhar at debian.org>
>   86 <noel at debian.org>
>   81 <dlehn at debian.org>
> (...)

Je note au passage que Samuel Hocevar (sam+deb at zoy.org) serait donc
capable de maintenir un nombre de packages impressionnant sans un seul
bug (RC ou pas) ? Ca paraît difficile à croire, mais de toute façon,
pour l'avoir cotoyé à Alcôve (il y était alors stagiaire) il y a 3
ans, je le rangeais déjà bien volontiers dans la catégorie des
surhommes. :-)

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

> Et s'il n'y a pas de liste ?  Bien sûr, tout *BON* développeur de
> logiciel libre devrait fournir une mailing-list...  Les autres ne
> sont d'ailleurs que des mauvais, je me demande pourquoi on utilise
> leurs logiciels.

Malgré le ton ironique, c'est vrai au sens propre pour des projets
ayant déjà acquis une certaine taille.
Si le développeur d'un projet d'une taille certaine n'a pas fait
l'effort de mettre à disposition au moins une mailing-list, c'est
probablement que l'interaction avec ses utilisateurs potentiels ne
l'intéresse pas beaucoup, et il a donc de fortes chances d'être ce que
j'appelle un "mauvais" développeur libre (car pour moi, il n'y a pas que
la qualité technique pure d'un programme qui compte).

Maintenant, une fois de plus, tu ne me feras pas dire ce que je n'ai
pas dit. Car je l'ai dit (huh ?) : c'est bien que ce mécanisme (les
debian watch files) existe. Pour les petits paquets.

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

> Il y a le répertoire de la FSF et de l'UNESCO:
>   http://www.fsf.org/directory/

Mon Dieu (tm). Dans sa forme actuelle, ce truc m'inspire les remarques
suivantes :
- le schéma de la base de données n'est pas complet
- les champs ne sont pas assez structurés
- les informations ne sont pas à jour

Bref, cela n'apporte aucun gain par rapport à freshmeat sur le plan
technique (au contraire), mais cela a le grand avantage d'être libre,
et c'est déjà beaucoup.
Ce qu'il faudrait, maintenant, c'est reprendre en main tout ça,
l'améliorer grandement, ce qui équivaut à refaire un freshmeat,
en mieux. Une fois de plus, il faudrait refaire en grande partie ce qui
existe déjà... encore de l'énergie gaspillée, mais ainsi va la vie.

> > 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 qu'il n'y a pas le même effort de qualité upstream ?

Je ne suis pas sûr de comprendre la question. Et dans tous les sens
que je peux imaginer, je ne connaisa sans doute pas la réponse. :-)

> > - 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)

> À tempérer par l'activité sur discover2 ?

Non, point encore de discover2 à cette époque-là.

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

> Parce qu'il n'est pas parfois pas possible de backporter les
> corrections ?  Parce qu'on ne peut pas aveuglement packager une
> nouvelle version ?

> Le premier de "ta" liste, c'est gstreamer, corrigé dans gstreamer 0.8,
> qui est packagé, sous le nom gstreamer0.8 pour des raisons de
> dépendance.  Il y en a d'autres dans ce cas.  Supprime les, ça réduit
> la liste, tu dormiras mieux :)

Oh, je n'ai jamais dit que tous les bugs listés étaient inexplicables.
Mais quand tu enlèves tout ce qui l'est, il en reste encore trop.

Ah, tiens... encore un truc que je n'arrive pas à m'expliquer dans
Debian... c'est qu'il n'y ait pas de champ "Debian-related-only",
"uptream-related-only", "both" pour un bug.
Cela permettrait de faire de bien meilleures statistiques (et ça
éviterait de voir épidodiquement Debian classée à tort dans les
distributions les plus buguées par des comparatifs peu sérieux).

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

> Ce n'est pas Debian que tu critiques, ah, ça va mieux :)

C'est justement parce que je suis convaincu que Debian est "the way to
go" que certaines de ses insuffisances me sont plus pénibles que
d'autres. :-)

 Hervé

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