Qui suis-je

Je suis un tunisien et français de 32 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'installateur Debian, Debian autonome, la prise en charge de la sécurité, ainsi que divers rapports et correctifs de bogue). Nous projetons de publier cela sous forme de dérivée de Debian. Aussi attendez-vous à entendre parler de « Scibian », notre distro Linux pour le Calcul scientifique, en 2016. Vous pouvez trouver plus d'information à propos de Scibian en consultant notre exposé au Fosdem.

Bonus

Si vous lisez ces lignes, merci beaucoup ! Pour vous prouver ma gratitude, voici la recette des Waffles belges de Wouter Verhelst :

Appréciez ! Une fois que vous aurez dégusté vos waffles, vous pourrez continuer à lire mon programme. :-)

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.

OCaml Task Force

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

Wanna-Build Team

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 de la manière dont toutes les parties interagissent. Ce travail pourrait bénéficier au projet de nombreuses façons, telles que :

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 avons introduit des changements sociaux substantiels depuis une paire d'années (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.

Un autre aspect important concerne la communication. Debian est un énorme projet et une grande partie se déroule dans des équipes. Nous devons communiquer sur nos réalisations jour après jour et pas seulement lors d'évènements considérables comme les publications stables. À mon avis, cela pourrait attirer plus de monde et aider les membres actuels à rester en phase avec le projet. De la même façon, de nombreux développeurs ne suivent plus « debian-devel » pour différentes raisons. Je crois qu'il y existe des fils de discussions intéressantes et qu'un résumé succinct peut aider beaucoup de nous à appréhender les préoccupations actuelles.

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 les blocages s'il y en a.

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.

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.

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. Je pourrai consacrer 20% de mon temps de travail à des tâches Debian.