Qui je suis

Je suis un tunisien et français de 31 ans vivant près de Paris en France. J'ai le plaisir d'utiliser Linux depuis le lycée et ai installé Debian pour la première fois vers 2000.

Je travaille pour EDF (« Électricité de France ») en tant que responsable technique dans un groupe dédié à des tâches liées au calcul à haute performance (HPC) où j'ai eu le plaisir de rendre Debian utilisable tel quel sur certaines machines du TOP500. Nous nous assurons que Debian soit prête pour les environnements HPC du monde réel et déployons Debian sur des grappes HPC.

Au travail, j'ai également le plaisir d'interagir avec plusieurs développeurs Debian. Les modifications que nous apportons à nos distributions internes basées sur Debian ont aussi (partiellement) contribué en retour à Debian (slurm-llnl, la pile OFED, l'installeur Debian, Debian autonome, la prise en charge de la sécurité, ainsi que divers rapports et correctifs de bogue).

Contributions à Debian

J'ai fait ma thèse de doctorat au laboratoire PPS, où j'ai eu la chance de rencontrer, entre autres, Samuel Mimram, Ralf Treinen, Stefano Zacchiroli et Julien Cristau. Samuel a été un grand mentor et m'a encouragé à contribuer à Debian. Son enthousiasme pour Debian m'a fait une grande impression et m'a inspiré ces valeurs. En tant que mentor, il a commencé par m'assigner un bogue se produisant dans un programme que j'ai écrit. Malheureusement, son plan a échoué puisque le bogue est toujours ouvert ! #440469. Je suis toujours là, et c'est comme cela que mon histoire de contributeur Debian a débuté. :-)

Équipe OCaml

J'ai commencé à travailler dans l'équipe OCaml en regardant les bogues concernant nos paquets et en proposant des correctifs. Quand j'ai compris comment ça marchait, j'ai commencé à empaqueter de nouveaux programmes, des bibliothèques, et même un compilateur. Les paquets OCaml sont incroyablement dépendants les uns des autres et ont des besoins de transition complexes. Lors de DebConf9, nous avons travaillé sur un solveur automatique de dépendance pour les paquets OCaml (DH OCaml) et avons converti plus d'une centaine de paquets pour utiliser ce nouvel outil. Dans ce contexte, j'ai également étendu ocamlobjinfo pour exporter la liste des modules nécessaires pour divers types de fichiers générés (binaires en bytecode, bibliothèques chargeables dynamiquement, etc.). Le solveur automatique de dépendance utilisé aujourd'hui est construit autour de ce programme. Peu après notre déploiement dans Debian, nos modifications ont été intégrées en amont, aidant toute la communauté OCaml.

Les transitions OCaml sont gérées d'une façon spécifique puisque l'envoi d'un nouveau compilateur entraîne la programmation d'une reconstruction de tout l’environnement OCaml de Debian. Cela m'a aidé à mieux comprendre Debian et à entrer en contact avec d'autres équipes pour que nos nouveaux paquets soient mieux reconstruits et migrés.

Équipe Wanna-Build

Mes interactions avec l'équipe Wanna-Build m'ont fait réaliser que les pages de statut Buildd étaient (en quelque sorte) laissées à l'abandon à l'époque. Afin de pouvoir suivre nos transitions OCaml plus facilement ou juste pour rendre mon travail de mainteneur plus agréable, j'ai réalisé le besoin de nouvelles fonctionnalités, telles que la vue multipaquet, les Dep-Waits cliquables, le filtrage basé sur l'adresse du mainteneur (entre autres). J'ai donc totalement réécrit les pages de statut Buildd. À l'époque, il existait plusieurs versions des pages de statut. La situation des licences et du droit d'auteur n'était pas claire non plus. Le but de mon travail était de clarifier la situation et d'ajouter de nouvelles fonctionnalités à l'interface web, tout en maintenant les fonctionnalités existantes.

J'ai aussi travaillé à le rendre facile à déployer pour que d'autres instances wanna-build (debian-ports et clang.d.n) puissent en bénéficier sans effort.

Équipe en charge de la publication

J'ai rejoint l'équipe en charge de la publication en tant qu'assistant de publication pendant le cycle de développement de Squeeze. Mon objectif principal était d'aider l'équipe à gérer les transitions de bibliothèques dans Unstable. Avec cette idée en tête, j'ai travaillé sur l' outil de suivi de transition, basé sur un outil comme grep-dctrl, qui a été écrit à l'origine par Stéphane Glondu. Cet ensemble d'outils est mieux connu aujourd'hui sous le nom de Ben. Avec le temps, j'ai eu un rôle plus actif dans la revue des requêtes de déblocage faites pendant le gel.

UbuntuDiff

La collaboration avec les distributions dérivées en les aidant à remonter leurs correctifs en amont m'est importante. En 2010, j'ai écrit une interface web pour montrer les correctifs d'Ubuntu aux mainteneurs intéressés. Je prévois également de généraliser cela aux autres distributions dérivées.

Debian France

Je suis membre et soutien de Debian France, une organisation Debian de confiance (Debian trusted organization). Sous l'égide de Debian France, j'ai co-organisé des miniDebConf à Paris en 2010 et 2012.

Autre

En plus de mes activités dans Debian, j'ai aussi travaillé avec Jérôme Vouillon et Roberto Di Cosmo, de l'IRILL, sur un programme similaire à Britney appelé comigrate. Ce programme peut être utilisé en remplacement direct de Britney. Ses principaux avantages sont qu'il est très rapide et donne des explications très détaillées à propos des échecs de migration. comigrate peut être utilisé pour mieux comprendre les problèmes de migration ou comme un auto-hinter pour Britney.

Vision

Debian est un gros projet, En fait, il s'agit d'un des plus grands projets de logiciel libre. Nous faisons face aujourd'hui à des problèmes inhérents à notre taille et amplifiés par notre culture d'excellence technique.

Certaines des idées que je mentionne dans ce programme se concentrent sur la complexité de la collaboration au sein de Debian. Debian a tellement grandi qu'elle est devenue une fédération de plus petits projets (d'équipes). En conséquence, nous avons des difficultés à prendre des décisions qui passent à l'échelle du projet. Cela devient même un problème encore plus difficile lorsque le nombre de paquets grandit plus rapidement que le nombre de nouveaux contributeurs que nous sommes capables d'embarquer.

Améliorer nos processus

Afin de surmonter les problèmes mentionnés, je vais me lancer dans une revue de nos outils, mécanismes, processus et la manière dont toutes les parties interagissent. Ce travail pourrait bénéficier au projet de nombreuses façons, telles que :

  • l'identification des goulots d'étranglement non triviaux ;
  • une communication fluide entre les équipes ;
  • des objectifs partagés grâce à une stratégie cohérente ;
  • la réduction de la complexité de nos processus.

Je vais travailler à collecter et compiler un dépôt de cas d'utilisation de Debian qui pourra être utilisé par les contributeurs à trouver leur voie plus facilement dans le projet.

Feuille de route

Notre distribution est le principal produit livré au monde par notre projet. J'ai tendance à croire que nous ne faisons pas qu'empaqueter des projets amont et publier de nouvelles distributions. Debian offre plus que cela et a une valeur ajoutée. Les objectifs de publication étaient un moyen de montrer à quel point notre distribution est originale, pertinente et innovante. Même au niveau social, il est important d'établir des objectifs dans le but de motiver les potentiels contributeurs à rejoindre Debian. Nous, la communauté Debian, devrions travailler à publier et maintenir une feuille de route et faire notre possible pour la mettre en œuvre à chaque cycle. Il n'est pas nécessaire de l'avoir fait à temps pour une publication, mais il est important de suivre sa progression.

Je vais lancer une action pour aider le projet à publier une feuille de route ; avoir chaque élément décrit de façon S.M.A.R.T et m'assurer que des progrès sont faits. Je suis sûr que chaque équipe a son propre ensemble d'idées à mettre en œuvre. Néanmoins, il est important de centraliser ces idées pour leur donner plus de visibilité et avoir une meilleure vue d'ensemble.

Changer l'encadrement

Nous venons de traverser une année difficile. Nous avons introduit des changements sociaux substantiels (déclaration de diversité et code de conduite). Nous avons changé le système de démarrage par défaut. Certaines de nos figures historiques et importantes se sont retirées du projet. Nous nous sommes débarrassés des clés PGP de 1024 bits.

Bien que certains des changements mentionnés soient très bons pour le projet, leur mise en œuvre a été très difficile. Que nous parlions d'introduire un changement important dans notre façon de débattre ou sur comment nous devrions démarrer le système, il est important de considérer les détails d'implémentation, la chronologie et comment le changement sera mis en œuvre. Ces changements ne portent pas que sur la communication. Ces changements ne sont même pas à propos de faire le bon choix. Ils concernent, en revanche, comment chaque détail sera géré. Certains changements doivent être mis en œuvre graduellement − d'autres nécessiteront des tours de communication.

Je serai présent lors de la préparation des changements importants (qu'ils soient techniques, sociaux, financiers ou politiques) pour être certain que les détails de mise en œuvre aient été étudiés.

Recrutement

Recruter est difficile. Pourtant, nous n'avons pas essayé toutes les possibilités. Je suis convaincu que la revue des processus et de la documentation aidera cet aspect. Beaucoup de contributeurs potentiels ne nous rejoignent pas à cause du manque de documentation (déjà souligné lors des campagnes d'élections précédentes). Je ne pense pas qu'il soit possible d'arranger ce problème en un an, mais je suis d'accord avec le fait que nous devrions poursuivre nos efforts à ce sujet.

Nous participons déjà à des programmes de stages (comme Outreachy et GSoC) mais nous devrions également envisager de sponsoriser de tels programmes ou de faire le nôtre qui serait ouvert à tous. GSoC est un très bon programme mais qui se concentre sur des projets très techniques et longs. Le moment du GSoC rend la participation des étudiants de l'hémisphère sud difficile. Nous manquons d'un programme se concentrant (simplement) sur la familiarisation de plus de personnes avec le projet, sa philosophie, sa communauté, ses processus et son fonctionnement. J'aimerais encourager les initiatives comme le programme de mentor de Debian Women et le Mentoring of the Month (MoM) de l'équipe DebianMed, et les généraliser pour ne pas être purement concentrées sur les tâches d'empaquetage. Je vois cela comme une opportunité de joindre des efforts et créer un programme de mentorat généralisé et à l'échelle du projet. D'un point de vue plus général, nous manquons également d'une équipe de rayonnement (Outreach team) qui pourrait s'occuper de la représentation de Debian dans les programmes de stage.

Adapter Debian aux continuels changements du monde

Parfois, nous sommes tellement concentrés sur nos tâches quotidiennes que nous ne remarquons pas comment le monde bouge autour de nous. Nous devrions nous assurer que Debian soit toujours innovante et relève les nouveaux défis.

Un exemple est le média d'installation : bien que nos plus grands sponsors dans le passé aient été des fabricants et des hébergeurs, aujourd'hui les acteurs de l'informatique dans les nuages nous ont rejoints et l'utilisation de systèmes virtualisés est devenue très courante. Pourtant, nous ne livrons que des images d'installation, mais pas d'image de systèmes pré-construits (dans divers formats) ni d'image de systèmes virtuels. Aurélien Jarno fournit des images Qemu depuis un certain temps mais je pense que de telles initiatives devraient être plus officielles et mises en avant. Le statut des images système pour différents fournisseurs de nuage est également flou et mériterait un peu d'attention.

Nous nous sommes habitués à ce que nous avons. Nous devrions faire des efforts pour innover et assurer que la façon dont nous faisons Debian est toujours pertinente pour le monde. Nous devons nous assurer que la façon dont nous installons et déployons Debian est pertinente pour nos utilisateurs, parce qu'ils sont notre priorité. Nous devrions nous assurer que les besoins de nos utilisateurs sont comblés !

Il fut un temps où le plus grand défi était de faire une distribution. Aujourd'hui, nous devons aller de l'avant et imaginer de nouvelles façons d'installer Debian, de la rendre plus sûre, de rendre ses mises à niveau incassables, de la rendre plus simple à utiliser, de réaliser une publication continue. Bien sûr, ce ne sont pas des questions triviales et je ne prétends pas avoir les réponses. Les solutions et idées viendront des contributeurs. Les solutions viendront de vous ! Ne soyez pas timides et faites des propositions.

L'innovation n'est pas un sujet facile. Pour chaque domaine, nous devons faire un état de l'art, être créatifs et mettre les choses en perspective. J'étudierai les propositions et aiderai les gens à lancer leur projet et à résoudre tout point bloquant.

Approche

Le rôle du DPL est central et chaque DPL a dû gérer différents types de requêtes (financières, légales, sociales, techniques, politiques). Ces requêtes ne font pas que consommer beaucoup d'énergie, elles représentent aussi un pourcentage important de l'activité globale du DPL.

J'ai l'intention d'être aussi transparent que possible. Je tiendrai un journal du DPL listant les sujets courants et les actions prévues. Je communiquerai sur ces sujets et essaierai de décrire les progrès accomplis. Je veux que les communications du DPL atteignent plus de personnes. Pour cela, je ne veux pas compter seulement sur d-d-a. Avec l'aide de l'équipe en charge de la publicité, j'aimerais compter sur bits.d.o en tant qu'outil de communication qui aiderait à atteindre une audience plus large.

Je ne prévois pas de centraliser toutes les tâches, mais appellerai les développeurs Debian à l'aide autant que possible. J'inviterai les bons orateurs parmi les DD à représenter le projet au lieu de laisser le projet ne compter que sur le DPL.

En tant que facilitateur et médiateur, je prendrai part aux discussions importantes et travaillerai à créer des résumés clairs afin de clarifier les longues discussions. Mon espoir est que cela nous permettra d'atteindre un consensus plus efficacement.

Je vais suivre la même stratégie que les DPL précédents et encourager les rencontres de développeurs (sprints, chasse aux bogues et miniDebConf). De plus, j'essaierai d'encourager les rencontres entre équipes lorsque cela sera pertinent.

Plus important, j'ai remporté le jeu du DPL ! Je suis sûr que les capacités qui m'ont aidé à gagner me seront également très utiles en tant que DPL ! :-)

Engagement en temps

Le rôle de responsable du projet Debian est très chronophage. Afin de le remplir sérieusement, je mettrai en pause mes autres activités dans Debian pour la durée de mon mandat.

Il est vrai que le temps que je peux consacrer à Debian s'est considérablement réduit au cours des dernières années. C'est principalement dû au fait que j'ai changé d'emploi et obtenu plus de responsabilités. J'ai eu la chance d'avoir des jumeaux en 2012 − jumeaux qui ont grandi, et je suis capable de consacrer plus de temps sur Debian de nouveau.

Enfin, je ne serai pas capable d'être un DPL à plein temps. À la place, j'ai le soutien total de mon employeur, qui encourage beaucoup le travail que nous faisons sur Debian. Si nécessaire, j'ai également la possibilité de prendre quelques jours de congé sans interférer avec les vacances prévues en famille. Mon équipe me soutient également et je sais que je peux me décharger de certaines de mes tâches quotidiennes si nécessaire.

Réfutations

Gergely Nagy

Le programme de Gergely est plutôt unique et diffère des programmes que nous avons tous les ans, le mien compris. Il insiste que s'il est élu, il ne sera pas aussi disponible pour le projet que ce qu'il souhaiterait.

Plus tard dans son programme, Gergely se concentre sur le bonheur des contributeurs. Il aimerait agir comme un facilitateur et aider les gens à réaliser leurs projets. Bien que ce soit un objectif très noble, celui-ci semble contradictoire avec sa faible disponibilité pour le projet. Les fardeaux administratifs et bureaucrates prennent du temps et il n'explique pas comment il sera capable d'accomplir ces tâches en un temps réduit.

J'aurais aimé en lire plus sur ses plans s'il est élu. Cela aurait aidé à mieux comprendre sa vision du projet et ses priorités.

Neil McGovern

Neil explique bien ses contributions passées au sein de Debian et montre son expérience dans des domaines variés du projet. Je suis en accord avec sa vision du statut actuel du projet et sur la liste des idées qu'il aimerait voir mises en œuvre s'il est élu responsable du projet. Ces idées sont importantes pour le projet, mais certaines d'entre elles ne sont pas très spécifiques.

J'ai été surpris de ne rien voir au sujet de nouvelles façons d'atteindre de nouveaux contributeurs et du peu d'éléments sur la façon de décider d'une direction pour le projet.

Neil explique qu'il a réutilisé son programme de la campagne de l'an dernier car il est toujours pertinent et a souligné que ses propositions n'ont toujours pas été mises en œuvre. Bien que cela soit vrai, beaucoup de choses se sont passées au sein du projet depuis l'an dernier et cela aurait mérité quelques notes à ce sujet.