--
#use wml::debian::template title="Programme de responsable du projet de Ben Collins" #use wml::debian::translation-check translation="1.3" maintainer="Nicolas Bertolissio" <pre> 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 le système 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'auto-construction 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, MacOS 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. </pre>
Attachment:
signature.asc
Description: Digital signature