Programme de DPL 2019

Je suis développeur Debian depuis 17 ans, ayant rejoint Debian en avril 2012. Les gens dans la vie réelle pensent que je suis « LA RÉPONSE » depuis mi-mars, car j'ai 42 ans depuis peu. Je vis dans une charmante ville moyenne appelée Fulda, en plein centre de l'Allemagne.

J'ai tenu divers stands pour Debian dans un certain nombre de manifestations au fil des ans. Cela a été le cas pendant plusieurs LinuxTag, LinuxWorldExpo et Cebit, ainsi que lors de Journées Linux de Chemitz, du FrosCon et d'autres manifestations plus modestes. Parfois je ne faisais qu'être présent, mais dans d'autres cas, j'ai géré toute l'organisation nécessaire, y compris la production de CD ou DVD Debian à distribuer aux visiteurs aussi bien que la présentation de produits. C'est durant la première de ces manifestations que j'ai trouvé mon premier paquet à entretenir (ou plutôt c'est le développeur amont qui m'a trouvé).

Je suis devenu responsable de candidature dans le processus du nouveau membre peu de temps après être devenu DD puis gestionnaire adjoint de compte Debian en 2004 avant de devenir gestionnaire de compte à part entière (DAM) en avril 2008.

En mars 2005, j'ai rejoint l'équipe FTP comme assistant et suis devenu un responsable de l'archive (FTP Master) en avril 2008.

Après la DebConf5, j'ai rejoint l'organisation des DebConf avec comme rôle principal celui de l'administration de l'infrastructure, à l'époque où elle était distincte de Debian. Au-delà du travail d'administration, j'ai aidé ou piloté plusieurs équipes comme celle en charge du programme ou du soutien financier aux déplacements.

Je fais partie du groupe d'administration des miroirs, et j'ai écrit la base de l'ensemble de scripts de synchronisation des miroirs avec le site principal.

Je suis un des administrateurs de notre Debian Planet ainsi que du service gitlab de Debian salsa.debian.org.

Je suis aussi membre de l'équipe (NOC - Centre d’opération réseau) d'OFTC, du réseau IRC vers lequel pointe irc.debian.org.

Entre 2007 et février 2018, j'ai été membre du bureau de SPI, (« Software in the Public Interest », logiciel d'intérêt public), la plupart du temps comme vice-président et administrateur principal. SPI est la couverture légale dans laquelle Debian réside aux États-Unis, et qui détient la majorité des avoirs de Debian.

C'est à nouveau le moment dans l'année. Il y beaucoup de monde sur la ligne de départ, prêts à poser une rafale de questions sur la liste -vote, avec seulement cinq candidats pour répondre. C'est la période d'élection du DPL et des longues discussions sur la liste. Tout le monde veut savoir comment le prochain chef du projet va nous mener vers le futur glorieux du système d'exploitation universel.

Comment relever tous les défis qui se posent à une distribution comme la nôtre, comment s'adapter à un monde qui évolue toujours plus vite ?

Comment devenir plus attractif pour toutes les entités commerciales qui choisissent actuellement d'ignorer Debian mais préfèrent une distribution dérivée ?

Comment devenir plus attractif pour les développeurs ?

Comment renouveler nos outils pour un flux de travail plus moderne ? Il y a un désir partagé de moderniser le BTS (une interface web, quelqu'un ?), ou pour des envois avec un « git push ».

Comment améliorer la diversité ? (Il suffit de regarder la liste des candidats cette année…)

Comment simplifier des modifications à grande échelle dans Debian ?

Comment traiter la mentalité « curl | sudo bash » des langages les plus récents et de leur environnement ? Comment inclure utilement ces langages ?

Et j'en suis sûr, beaucoup d'autres questions.

Je ne suis pas très bon pour prédire l'avenir, mais il y une chose sur laquelle je suis prêt à parier, c'est que Debian continuera à être pertinent pour la communauté. Nous avons beaucoup d'utilisateurs, directs ou indirects au travers des dérivées de Debian. Ils continuent à avoir besoin d'un système stable, prévisible et qui fonctionne tout simplement, ce que nous sommes doués pour le fournir.

Nous ne devrions pas nous relâcher ni nous contenter d'être juste un socle pour les autres, nous devrions examiner pourquoi les gens recherchent autre chose que Debian. Et voir si nous pouvons améliorer Debian pour fournir de nouvelles fonctionnalités, tout en gardant l'équilibre avec nos utilisateurs actuels. Et oui, cela comprend les utilisateurs qui construisent leurs distributions sur la nôtre.

Nous devons répondre aux besoins de nos millions d'utilisateurs. Leur éventail est vaste, de ceux qui souhaitent un système vraiment stable et répugnent au changement à ceux qui trouvent même que notre distribution unstable est trop lente à évoluer.

Ce n'est pas une tâche impossible, nous avons des gens parmi les plus brillants qui travaillent avec le projet. Nous sommes les experts pour assurer l'intégration de nos logiciels. Et nous devons nous assurer de sauvegarder ces propriétés et les étendre aux nouveaux défis.

Et certains de ces défis sont énormes. Le battage actuel sur les « parfaites manières de faire sysadmin/devops/… » est rarement basé sur des distributions complètes.

Dans la mesure ou le DPL n'est pas le leader du développement technique effectif, ce n'est pas au DPL de trouver des solutions techniques aux défis auxquels nous faisons face. Ni de trouver des réponses parfaites à la série de questions que j'ai posées plus haut (et à toutes les autres).

Mais le DPL doit permettre à d'autres membres du projet de le faire, et cela constitue un rôle majeur sur lequel je mettrai l'accent. Beaucoup des points que j'ai évoqués ne sont pas de ceux qui peuvent être mis en œuvre à court terme, en un an par exemple, mais on peut au moins commencer à les traiter. Certains ont déjà commencé à le faire, et il est important de poursuivre ce travail et d'entretenir l'engagement des gens.

Le DPL devrait travailler à supprimer les blocages et permettre aux développeurs de poursuivre leur travail.

C'est aussi le travail du DPL d'être à l'écoute. Et d'être guidé par la communauté.

Debian ne consiste pas seulement à empaqueter et à d'autres tâches techniques similaires, nous avons beaucoup d'autres contributions aussi importantes. Nous avons besoin d'encourager plus de gens qui ne connaissent pas bien le travail technique à contribuer dans divers domaines non techniques. Cela va de l'écriture de documentations, des traductions, de la contribution au site web, au travail de conception, à l'assistance aux utilisateurs ou bien à la représentation de Debian à des manifestations. Ou à organiser des événements, tels que des chasses aux bogues ou des réunions de « miniDebconf ». Tout cela est aussi important que le travail des empaqueteurs.

Je travaillerai avec tous ceux qui souhaitent améliorer les processus à l'intérieur de Debian pour identifier les obstacles importants, pour réduire notre complexité et pour améliorer la communication entre les équipes si besoin est.

J'ai l'intention de poursuivre la démarche de transparence de Chris (et d'autres anciens DPL) avec des rapports d'activité réguliers, bien que mon style sera naturellement différent.

Aussi, comme nous sommes dans un projet vraiment énorme, il y a des secteurs où je n'en sais pas assez (voire rien). Je n'ai pas peur de demander de l'aide.

Le travail de DPL est un de ceux qui réclament beaucoup de temps et d'énergie. Avoir un travail à temps complet et une famille avec deux enfants ne facilite pas les choses. À ce sujet, j'ai discuté avec tous ceux qui étaient concernés et j'ai obtenu leur soutien plein et entier pour ma candidature.

Pour être plus précis : mon entreprise a compté 45 journées à employer pour mes fonctions de DPL (sur les environs 250 jours travaillés que compte un mandat de DPL), en plus de mes jours de congé habituels.

Le temps que je prendrai dépendra des tâches réelles du DPL et cela pourra aller de quelques heures par jour à des absences complètes pour me rendre à des manifestations.

Ce n'est que ce que je prendrai sur mon temps de travail, le temps effectif dont je pourrai disposer pour mes obligations de DPL sera plus important, mais je ne vais pas en faire un décompte définitif. Je l'ajusterai aux besoins, lorsqu'il le faudra.

Commençons par la plus importante dans ce contexte, celle de DAM. La constitution est claire dans ce cas. Le paragraphe 8.1.2 lui est consacré. Il précise :

Les délégués du chef du projet :

[…]

Ils peuvent prendre certaines décisions que le DPL ne peut pas prendre lui-même directement, y compris l'acceptation ou l'expulsion de développeurs, ou en désignant comme développeur des personnes qui n'entretiennent pas de paquets. Cela est fait pour éviter une concentration du pouvoir dans les mains du DPL, en particulier pour l'affiliation des développeurs.

La conclusion à tirer est simple, si je suis élu, je me retirerai du rôle de DAM.

Au-delà de la citation ci-dessus, la constitution n'interdit que la candidature du secrétaire et du président du CTTE pour le poste de DPL, et donc je ne vois pas de conflit qui m'interdise de conserver mon autre délégation, celle de FTP Master. Autrement dit, quand le moment sera venu de la renouveler, je devrai l'abandonner dans la mesure où le DPL ne peut pas s'accorder de délégation.