Who I Am
I am a 31 year old Tunisian and French, living near Paris, France. I've enjoyed using Linux since high school, and installed Debian for the first time circa 2000.
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.
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 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. :-)
OCaml Task Force
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
Adapting Debian to the continuously changing world
Sometimes we are so much focused on our daily tasks that we don't notice how the world is moving around us. We should make sure Debian is still innovating and embracing new challenges.
One example is installation media: While our biggest sponsors in the past were manufacturers and hosters, today cloud actors joined us and usage of virtualized systems became very common. Still, we are only shipping installer images, but not pre-built system images (in various formats) or virtual system images. Aurélien Jarno has been providing Qemu images for quite some time now but I think that such initiatives could be more official and advertized. The status of system images for various Cloud providers is also not so clear and would deserve some attention.
We got used to what we have. We should work on innovating and making sure the way we do Debian is still relevant to the world. We have to make sure that the way we install and deploy Debian is relevant to our users, because they are our priority. We should make sure that our users' concerns are fulfilled!
It's been a time where the biggest challenge was to make a distribution. Today, we have to go forward and imagine new ways of installing Debian, getting it more secure, getting upgrades unbreakable, getting it easier to use, getting it rolling. Of course, those are not trivial questions and I don't claim I have answers. Solutions and ideas will come from contributors. Solutions will come from you! Do not be shy and do make proposals.
Innovation is not an easy topic. For each area, we have to study the state of the art, be creative and put things into perspective. I will study proposals and help people getting their project started and resolving blockers if any.
The DPL role is central and every DPL has had to deal with various kinds of requests (financial, legal, social, technical, political). These requests not only take a serious amount of energy to deal with but also represent some fair percentage of the overall DPL activity.
I intend to be as transparent as possible. I will maintain a DPL journal listing current subjects and planned actions. I will communicate on these subjects and try to describe progress made. I want DPL communications to reach out more persons. In order to achieve that, I don't want to rely solely on d-d-a. With the help of the publicity team, I'd like to count on bits.d.o as a communication tool which will help to reach a broader audience.
I do not intend to centralize all tasks, but will call for help DDs whenever possible. I will invite DDs who are good speakers to represent the project, rather then the project relying solely on the DPL.
I will as a facilitator, mediator, take part in important discussions and work to create clear summaries in order to clarify lengthy threads. My hope is this allows us to reach consensus more effectively.
I will continue on the same strategy as past DPLs and encourage developers meetings (sprints, bug squashing parties, and mini-debconfs). Furthermore, I will try to encourage multi-team sprints when relevant.
More importantly, I've been the winner of the DPL game! I am sure the ability that helped me to win will also be very helpful while being a DPL! :-)
The DPL role is very time-consuming. To be able to do it seriously, I will put on hold my other Debian activities for the duration of the mandate.
It is true that the amount of time I am able to dedicate to Debian reduced considerably since a few years. This was mainly due to the fact I've changed my job and gained more responsibilities. I've been blessed with twins in 2012 -- twins that have grown up since then, and I am able to spend more time on Debian tasks again.
Last but not least, I will not be able to be a full-time DPL. Instead, I have the full support of my employer, who is very supportive of the work we do on Debian. If necessary, I have also the possibility to take some days off from work without interfering with holidays planned with family. My team is also supportive and I know how I can offload some of my day-to-day tasks if needed.
Gergely's platform is quite unique and differs from the usual DPL platform we have every year, mine included. He emphasises that if elected, he won't be available for the project as much as he would like to.
Later in the platform, Gergely focuses on contributors' happiness. He would like to act as an "enabler" and help people make their project come true. While this is a very noble goal, it seems contradictory with his availability for the project. Administrative and bureaucracy burden tend to take a fair amount of time and he doesn't explain how he will be able to achieve those tasks in a short time frame.
I would have liked to read more about his plans if elected. This would have helped to better understand his vision of the project and its priorities.
Neil explains well his past contributions within Debian and shows his experience in various areas of our project. I agree with Neil's vision of the current status of the project and on the list of ideas he would like to see implemented if elected as DPL. They are important for the project, but some of them are not very specific.
I was surprised not to see something about new ways to reach out new contributors and a few hints on how to decide a direction for the project.
Neil explains that he reused his platform from last year's campaign as it is still relevant and outlined that his proposed plans are still not implemented. While this is certainly true, a lot happened in the project since last year and that would deserve a few notes about it.