Programme de responsable du projet de Ben Collins

Ceci est l'annonce officielle de ma candidature au poste de responsable du
projet Debian. Je vais entrer dans les détails afin que ceux qui ne me
connaissent pas puissent prendre connaissance de mes convictions et de mes
visions de comment je devrais prendre le poste de responsable du projet
Debian si je suis élu.

Tout d'abord, comme la plupart des gens veulent certaines informations
personnelles sur les candidats, je vais commencer par cela. Je ne peux
qu'être d'accord que, pour un poste d'une telle importance, les
développeurs devraient connaître tout ce qu'ils peuvent sur les candidats.

Nom : Ben Collins
Âge : 26 ans
Situation familiale : Marié, un enfant de 2 ans (et oui, je passe bien
                      assez de temps avec ma famille :)

Poste actuel : administrateur de groupe Unix pour le centre de recherche
de Langley de la NASA. Notre groupe s'occupe principalement de
l'administration et de l'aide pour les système Unix utilisés par des
utilisateurs grands publics. Je m'occupe personnellement de la plupart du
développement pour ce groupe et de certaines tâches d'administration. Il y
a quelques projets significatifs que je poursuis (significatifs pour mes
capacités puisqu'ils ont un rapport avec le responsable du projet Debian)
dont je parlerai plus tard dans ce courriel.

Ma carrière informatique a débuté à 16 ans avec mon premier travail, dans
une compagnie de publication assistée par ordinateur qui utilisait des
Xerox 6085 (elles sont mauvaises, prennent 15 minutes à démarrer et se
bloquent plus souvent que Windows, vous vous demandez pourquoi ils n'ont
jamais percé le marché ?). Ensuite j'ai commencé à tirer parti des
compétences de programmation de base que j'avais acquises chez moi. Quand
je dis « de base », c'est VRAIMENT « de base », sur un Apple 2e avec un
lecteur de cassettes et deux lecteurs de disquettes 5 pouces ¼.
Depuis j'ai recherché du travail de plus en plus stimulant, de
fournisseurs d'accès à l'Internet aux petits magasins.

Je vais continuer et être honnête, je n'ai aucun cursus universitaire, en
dehors de quelques cours que j'avais suivis pendant mon apprentissage au
chantier naval de Norfolk. Je ne m'étalerai pas sur les raisons d'ordre
privées de cela. Tout ce que je sais, je l'ai appris moi-même, et bien que
je ne mésestime pas une bonne éducation, je crois qu'une réelle richesse
de connaissance est nourrie par le désire d'apprendre, non par la simple
recherche d'encadrer un diplôme sur un mur. J'ai un profond respect pour
tous ceux qui ont le temps et les ressources pour arriver à un haut niveau
d'étude et utiliser leur base de connaissance et leurs compétences, quoi
qu'ils en fassent.

Mon avis personnel sur le projet Debian actuel :

Je suis resté assez discret pendant certaines des discussions enflammées
sur quelques points clés qui touchent Debian maintenant. Il y a plusieurs
raisons à cela. La principale étant que je n'étais pas assez au courant de
tous les aspects en jeu jusqu'à récemment. Je ne suis pas de ceux qui
prennent position et qui s'expriment sur quelque chose sur laquelle je ne
pense pas avoir suffisamment de connaissance pour le faire. Je vais
examiner les autres raisons un peu plus bas.

Avant que je n'aborde mon point de vue sur ces questions, je voudrais
brièvement m'étendre sur ce que je crois être les problèmes qui affectent
le projet Debian aujourd'hui. Principalement parce que je pense qu'ils
sont bien plus importants que ce que chacun semble actuellement le croire.
Il me semble que le groupe dans son entier a perdu de vue nos objectifs
principaux, et alors que chacun les connaît, on ne leur consacre pas le
temps et l'énergie dont ils ont besoin. Ces objectifs sont indiqués dans
notre contrat social, et je pense que le plus important d'entre eux est le
quatrième ci-dessous :

| 4. Nos priorités sont nos utilisateurs et les logiciels libres
|
| Les besoins de nos utilisateurs et de la communauté des logiciels libres
| nous guideront. Nous placerons leurs intérêts en tête de nos priorités.
| Nous assumerons les besoins opérationnels de nos utilisateurs dans de
| nombreux types d'environnements informatiques différents. Nous ne nous
| opposerons pas aux logiciels commerciaux prévus pour fonctionner sur les
| systèmes Debian, et nous permettrons que d'autres créent des
| distributions à valeur ajoutée contenant conjointement des logiciels
| Debian et des logiciels commerciaux, et ceci sans réclamer aucune
| rétribution. Pour assumer ces objectifs, nous fournirons un système
| intégré de haute qualité, composé en totalité de logiciels libres, sans
| restrictions égales qui empêcheraient ce type d'usage.

Mon interprétation de ceci est qu'il faut se concentrer sur la fourniture
d'une distribution qui non seulement est libre selon la définition des
principes du logiciel libre selon Debian, mais qui également est
utilisable par les utilisateurs. C'est-à-dire qu'elle doit être aussi
stable et dénuée de bogues que possible. Actuellement nous avons des
bogues très anciens dans nos paquets, et notre manque d'attention n'est
pas très bien perçu.

J'ai repris l'un de ces paquets qui a été publié dans Hamm avec un bogue
grave qui pouvait corrompre le superbloc de temps en temps. C'est pour moi
inacceptable. Nous avons des douzaines de demandes de fonctionnalités et
propositions de normes qui sont toutes de très bonnes idées, mais qui sont
sans arrêt mises de côté par des discussions et des sujets actuellement
hors des limites de notre groupe.

Je ne suis pas en train de dire que nous, les développeurs, ou le projet
Debian dans son ensemble, de devrions pas nous impliquer dans ces sujets
externes, mais nous devrions plus nous concentrer sur nos objectifs
initiaux.

Mes objectifs en tant que responsable du projet seront de recentrer le
projet Debian sur ces objectifs.

1. Créer une distribution stable et dénuée de bogues pour nos utilisateurs ;
2. M'assurer que nous suivons nos lignes de conduite en ce qui concerne la
   « liberté » de la distribution.

J'ai plusieurs idées sur la façon d'arriver à ces buts. D'abord
restructurer légèrement la façon dont est gérée la distribution. Notre
méthode actuelle est de toujours avoir une distribution stable et une
instable. Une fois que l'instable est acceptée, elle devient gelée et une
nouvelle instable en est extraite.

Pour moi, cela s'est montré légèrement lourd à gérer pour ce qui est de
rester fixé sur un but. Comme il y a une nouvelle distribution instable,
les développeurs ont continué à suivre les dernières éditions originelles
et à empaqueter de nouveaux logiciels pendant qu'il reste beaucoup de
bogues à gérer dans la distribution gelée.

Les sujets sur debian-devel vont de problèmes de licence pour des
logiciels qui n'ont actuellement rien à voir avec Debian à une nouvelle
proposition de principes du logiciel libre selon Debian. Tout cela, bien
qu'important, est plutôt hors sujet pour les problèmes immédiats que nous
avons, « sortir ce produit ». Ce produit étant la distribution actuelle.

Voici plusieurs propositions que je poursuivrai si je deviens responsable
du projet :

1. Lorsqu'une distribution instable est gelée, il ne devrait pas en sortir
une nouvelle branche instable avant qu'elle ne soit profondément gelée.
Ceci devrait permettre d'accélérer la suppression de la porte du panneau
« En travaux ». Je ne dis pas du tout que nous devrions prendre quelques
raccourcis, mais plus nous restons gelés, plus les versions des paquets
originelles vieillissent, et plus vite elles se périment. En n'ayant pas
besoin de s'occuper d'une distribution instable, l'attention pourrait
rester fixée sur les bogues restants de la version gelée ;

2. Une autre idée possible, une de celles qui pourraient ne pas être très
bien reçues, mais une de ses variantes pourrait au moins être utilisée.
Une fois que le gel est profond, un groupe pourrait être désigné pour
évaluer les bogues affectant la distribution gelée. Il y aurait un nombre
défini de développeurs choisis au hasard dans le groupe et une personne
agissant en qualité de responsable du groupe (le groupe des bogues :).

Ce groupe initierait un contact avec les responsables dont les paquets
seraient affectés de bogues critiques pour la sortie de la prochaine
version. Le responsable du paquet aurait une semaine pour expliquer ce
qu'il ou elle fait pour résoudre les bogues. Si le responsable ne répond
pas, déclare ne pas travailler sur ces bogues, ou n'a pas la capacité de
les corriger, alors le groupe devrait soit prendre la responsabilité du
bogue, soit essayer de trouver quelqu'un pour le faire.

Cela assurerait que tous les bogues soient pris en compte et étudiés d'une
façon organisée. Actuellement, le seul moyen de s'occuper de cette
situation est par les mises à jour indépendantes, qui ont parfois causé
certains désaccords entre les responsables actuels et les développeurs qui
pensaient aider ;

3. Rendre disponibles des listes dynamiques pour les débats importants.
Cela permettrait de séparer les débats principaux, comme un problème
important de licence ou une modification de la charte, des discussions
générales de -devel qui nous éloignent souvent des détails urgents qui ont
besoins d'être traités en premier.

Le créateur de la liste aurait la possibilité de la clôturer lorsqu'elle
ne serait plus utilisée.


J'espère que vous avez compris que je m'attache aux détails. Bien que ces
grands sujets soient importants pour chacun de nous, en tant que groupe
nous devons rester plus concentré sur nos objectifs principaux et aborder
ceux des détails qui ont le plus d'impact direct sur Debian.

Nous ne pouvons pas être une organisation respectée dans la communauté du
logiciel libre si nous ne pouvons pas gérer nos affaires internes plus
efficacement et trouver de meilleures solutions.

Passons maintenant à mes projets en cours. Voici les principaux projets
sur lesquels je travaille :

Solaris/Dpkg : je développe actuellement un paquet de remplacement pour
cicero (un système propriétaire maison). Dpkg/dselect est optimal pour gérer
cela. Je prévois de poursuivre vers une distribution de ce portage de dpkg (que
ce soit sous Debian ou pas dépend d'un consensus général avec d'autres
personnes) comprenant des binaires ou des sources utilisables sous Solaris avec
elle. La maintenance du système tourne (évidemment) autour de dpkg/dselect. Les
méthodes ftp et nfs sont utilisées avec toute la puissance qu'elles permettent
ainsi que l'autoconstruction de certains paquets. Tout cela est toujours en
cours d'évaluation et de développement.

Linux à la NASA : quelques autres défenseurs de Linux ici à la NASA et
moi-même poussons pour que soit menée une évaluation de Linux comme
remplaçant de Windows, Mac OS et Solaris en tant qu'environnement de
bureau. Nous avons récemment reçu un peu de reconnaissance par des
gestionnaires sur la faisabilité. Un projet pilote est imminent.

vMac : vMac, l'émulateur Macintosh. Je ne suis que légèrement impliqué
dans ce projet. Je pourrais être plus actif, mais je n'ai pas beaucoup
d'expérience dans l'émulation de microprocesseurs.

Je travaille également sur quelques autres projets personnels, y compris
pour le petit groupe local en aidant au portage de DCE/DFS sur Linux. Ce
pourrait être un projet plus large si la licence d'OSF n'était pas aussi
stricte en ne permettant pas de distribuer de source ou de binaire (le
source est disponible, mais n'est distribué qu'à partir de leur site ftp).
Nous prévoyons de persuader OSF de rendre le source disponible sous une
licence plus ouverte.

Les problèmes :

Je sais que la plupart d'entre vous souhaitent connaître la position des
candidats sur les deux problèmes les plus chauds du moment.

Qt/KDE : je n'utilise pas KDE, non parce que je ne l'aime pas ou que j'ai
quelque chose contre KDE ou Qt, mais simplement parce que je travaille en
console, très peu sous X. Donnez-moi dix consoles virtuelles pour me
rendre heureux. Mon opinion sur ce point est très simple, il n'est pas de
la responsabilité de Debian de décider à quel point la QPL est bonne ni
comment la licence a besoin d'être modifiée, c'est le problème d'OSI ou de
SPI (c'est une toute autre question). Notre seule souci ici en tant que
groupe devrait être limité à déterminer si nos principes actuels sont
respectés ou pas, et si c'est le cas, qui va faire l'empaquetage. Sinon,
les archives de contribution et non libre sont disponibles. C'est tout.

J'encourage vivement toute personne voulant œuvrer pour obtenir une
licence plus compatible, et en tant qu'adepte des idéaux du logiciel
libre, j'espère que quelqu'un le fera. Restons simplement concentrés sur
le travail à faire et gardons ces choses pour des lieux plus appropriés.

DFSG 2 : je n'ai que brièvement jeté un coup d'œil à cela avant de
décider qu'après tout ce devait être abandonné. Je suis plus attaché à une
charte qui soit précise sur quelques points clés et plus générale sur ceux
qui sont moins importants. Par points clés, je pense toujours aux mêmes :
Le sources est-il disponible ? Le source et les binaires sont-ils
distribuables ? Pouvons-nous les modifier et fournir un source et des
binaires modifiés ?

Je sais que le dernier point est délicat. Je crois que la distribution du
source et de correctifs est aussi intéressante que celle du source
modifié. Tant qu'ils sont distribués ensemble.

Je ne pense pas que la charte devrait être très précise sur les points
triviaux ou controversés comme la clause sur les correctifs et les clause
de publicité de type BSD. D'après mon expérience, plus vous essayez d'être
précis sur quelque chose de cette façon, plus les gens essayent de trouver
des failles. Donc si nous rendons la charte plus stricte sur les points
clés et plus générale sur ceux qui sont moins importants, décider si un
paquet satisfait à nos exigences sera plus facile et moins sujet à des
influences extérieures.

Personnellement, l'idée que Debian soit le point central pour décider si
un paquet est libre ou pas ne me plaît pas. Nos objectifs en tant que
groupe n'incluent pas le fait d'être un gendarme du source ouvert. Cela
nous a donné la mauvaise image d'un mauvais garçon qui détient dans ses
mains le destin des logiciels des développeurs. Nous devons perdre cette
image. Même s'il s'agit d'une légère exagération de ma part, nous devons
vraiment perdre cette image.

Conclusion :
J'espère que mes idées sont prises avec sérieux. Même si je ne suis pas
élu comme responsable du projet, je pense que les points que j'ai soulevés
seront suivis afin de rendre Debian meilleur.

Je vous remercie.