At work, I have also the pleasure of interacting with several DDs. The changes we make to our internal Debian-based distribution are also (partly) contributed back to Debian (slurm-llnl, OFED stack, debian installer, debian live, security support, along with various bugs/patches).

I work for EDF (« Électricité de France ») as a technical manager to a group dedicated to HPC (High Performance Computing) related tasks where I have the pleasure of working on getting Debian ready to use out of the box for some TOP500 ranked machines. We focus on making sure that Debian is ready for real-world HPC environments and deploy Debian to the HPC clusters.

Besides my Debian activities, I've also worked with Jérôme Vouillon and Roberto Di Cosmo, from IRILL , on a Britney-like program called comigrate . This program can be used as a drop-in replacement for Britney. Its main advantages are that it's very fast, and gives very detailed explanations about migration failures. comigrate can be used to better understand migrations issues or as an auto-hinter for Britney.

Collaboration with derivatives in helping to guide downstreams to upstream their patches is important to me. In 2010, I wrote a web interface to expose Ubuntu patches to interested maintainers. I am also planning to generalize it to other derivatives as well.

I joined the Release Team as an Release Assistant during the Squeeze's development cycle. My main goal was to help the team to manage library transitions in Unstable. With that idea in mind, I worked on the transition tracker , based on a grep-dctrl like tool, which was initially written by Stéphane Glondu. This collection of tools is better known today as Ben . With time, I've taken on more of an active role in review of unblock requests made during freeze.

I've also worked to make it easy to deploy, so that other wanna-build instances ( debian-ports and clang.d.n ) can benefit from it without effort spent on integration.

My interactions with the Wanna-Build team made me realize that Buildd Status pages were (kind of) abandoned at that time. To be able to follow our OCaml transitions more easily or simply to make my work as a maintainer more enjoyable, I realized the need for some new features, such as a multi-package view, clickable Dep-Waits, filtering based on maintainer's address (among others). As a result, I volunteered to rewrite the Buildd Status pages from scratch. Back at that time, there were several versions of the status pages. The licensing and copyright situation was also not clear. The goal of my work was to get the situation cleared and add new features to the web interface, while simultaneously maintaining existing features.

OCaml transitions are handled in a specific way since an upload of a new compiler results in scheduling a rebuild of the whole Debian OCaml world. This helped me to better understand Debian and get in touch with other teams to have our new packages rebuilt correctly and migrated.

I started working with the OCaml Task Force by looking at bugs submitted against our packages and proposing patches. After I got the hang of that, I started to package new OCaml programs, libraries, and even a compiler. OCaml packages are insanely inter-dependent and have complex transition needs. During DebConf9, we worked on an automatic dependency resolver for OCaml packages (DH OCaml) and converted over a hundred of packages to take advantage of this new tool. In this context, I also extended ocamlobjinfo to to export the list of "needed" modules for various kinds of generated files (bytecode binaries, dynamically loadable libraries, etc...). The automatic dependency resolver in use today is built around that program. Soon after our deployment in Debian, our changes were upstreamed, helping the wider OCaml community.

I did my PhD thesis at the PPS laboratory, where I had the chance to meet, among others, Samuel Mimram, Ralf Treinen, Stefano Zacchiroli and Julien Cristau. Samuel was a great mentor and encouraged me to contribute to Debian. His enthusiasm for Debian made quite an impression, and helped instill those values in me. As a mentor, he started by tasking me with a bug occurring in a program I wrote. Unfortunately, his plan failed, since the bug is still open! #440469 ). I am still here, and that's how my story as a Debian contributor started. :-)

Vision

Debian is a big project. Actually, one of the biggest free and open source software projects. We are facing today some problems inherent to our size and amplified by our culture of technical excellence.

Some of the ideas that I mention in my platform focus on the complexity of collaboration inside Debian. The latter grew so much that it became a federation of smaller projects (team-sized). As a consequence, we are having hard time making solutions that scale to the size of the bigger project. This becomes even a more challenging problem when the number of packages grow more rapidly than we're able to onboard new contributors.

Improving our processes In hopes of overcoming the aforementioned problem, I will engage in a review of our tools, mechanisms, processes and how all parties interact together. This work may benefit the project in many ways, such as: identifying non-trivial bottlenecks,

smooth communication between teams,

shared goals using a single coherent strategy

reduction in complexity of our processes I will work on collecting and compiling a repository of Debian use cases that can be used by contributors to find their way more easily into the project.

Roadmap Our distribution is the main product delivered by our project to the world. I tend to believe that we don't only package upstream projects and publish new releases. Debian offers more than that and has its added value. Release Goals were one way to show how our distribution is original, relevant and innovating. Even on a social level, it is important to set some goals in order to continue to motivate prospective contributors into joining Debian. We, as the Debian community, should work to publish and maintain a roadmap, and strive to implement it each cycle. It is not necessary to have it done in time for a release, but it is more important to follow its progress. I will initiate an effort in order to help our project to publish a roadmap ; have each item described in a S.M.A.R.T way and make sure progress is made. I am sure that each team has its own set of ideas to implement. However, it is important to centralize those ideas to give them more visibility and have a better idea on the big picture.

Change management We've been through a tough year. We have introduced substantial social changes (Diversity statement and Code of conduct). We changed the default init system. Some historical and prominent figures of the project retired. We've got rid of 1k PGP keys. While some of the aforementioned changes are great to the project, their implementation was a real pain. Whether we're talking about introducing a substantial change in the way we discuss or how we should boot the system, it's important to consider implementation details, the timeline and how the change will be implemented. These changes were not only about communication. These changes are not even about making the correct choice. It is, however, about how every detail of the change will be handled. Some changes have to be implemented gradually -- others will require rounds of communication. I will be present during preparation of important changes (be them technical, social, financial or political) to ensure implementation details have been studied.

Recruitment Recruitment is hard. Yes. Yet, we did not try all the possibilities. I am convinced that the review of processes and documentation will help in that regard. Many potential contributors do not join because of the lack of documentation (as outlined in past DPL campaigns). I don't think it is possible to address this issue within a year, but I agree that we should continue our efforts on that front. We already participate in internship-programs (like Outreachy and GSoC) but we should also think about sponsoring such programs or make our own that is open to everyone. GSoC is a great program but it focuses on very technical and lengthy projects. The timing of GSoC makes it very hard for students from the southern hemisphere to participate. We lack a program that focuses on (simply) getting more people familiar with the project, its philosophy, its community, its processes and its work-flow. I would like to encourage initiatives like Debian Women Mentoring Program and Mentoring of the Month (MoM) by the DebianMed team and generalize it to not focus purely on packaging tasks. I see this as an opportunity to join efforts and create a more generalized and project-wide mentoring program. On a more general topic, we also lack an "Outreach team" which could take care of Debian representation in internship-programs.