Who I Am
I am a 32 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 related tasks (High Performance Computing) 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 also have 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). We plan to release it as a Debian derivative. So, expect to hear more about “Scibian”, our Linux distro for Scientific Computing, in 2016. You can find more information about Scibian by watching our Fosdem talk.
If you are reading these lines, thanks a lot! To prove you my gratitude, enjoy this Belgian Waffles recipe from Wouter Verhelst:
- Dissolve 20g of yeast in 200ml lukewarm water.
- Put 250g flour in a bowl, and slowly add the water with the yeast, while stirring.
- Add a bit of salt and 200ml of lukewarm milk.
- Separate the yellows and the whites of four eggs, add the yellows to the batter.
- Make sure there are no lumps left in the batter – use a mixer if necessary.
- Make foam of the whites of the eggs, and carefully add them to the batter together with 125g of molten butter.
- Let the batter raise for 15 to 20 minutes.
- Use a waffle iron with a coarse grid; apply some butter to the iron, or some other grease matter.
- Bake until you get a gold-yellow color.
- Add whipped cream or powdered sugar, and perhaps some strawberries or other fruit.
Enjoy! Once you’re done eating your waffles, you may continue reading my platform. :-)
I did my PhD thesis at the PPS laboratory, where I had the chance to meet Samuel Mimram, Ralf Treinen, Stefano Zacchiroli and Julien Cristau, among others. Samuel was a great mentor and encouraged me to contribute to Debian. His enthusiasm for Debian made quite an impression, and helped instill the values of the project in me. As a mentor, he started by tasking me with a bug occurring in a program I wrote.
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 deeply 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 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’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.
I joined the Release Team as an Release Assistant during the Squeeze 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 the 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. Today, we are facing 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. Debian has grown so much that it has become a federation of team-sized, smaller projects. As a consequence, we are having a hard time making solutions that scale up to the size of the bigger project. This becomes an even more challenging problem when the number of packages grows more rapidly than we’re able to onboard new contributors.
Improving our processes
In the hope 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 understanding of the big picture.
We have introduced substantial social changes a couple of years ago (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 interact 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.
Another important aspect is about communication. Debian is a wide project and a lot is going on within teams. We have to communicate about our day-to-day achievements and not only big events like stable releases. Im my opinion, this could attract more people and help current members to easily stay in touch with the project. Likewise, many developers do not follow “debian-devel” anymore for various reasons. I believe there are interesting threads in there and a quick summary may help many of us better understand current preoccupations.
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!
There was 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! I will encourage people not be shy and to 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 to more people. 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 Debian contributors whenever possible. I will invite Debian contributors who are good speakers to represent the project, rather than have the project rely solely on the DPL.
I will act 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 helps 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.
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.
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. I will be able to dedicate 20% of my work time to Debian tasks.