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.

Wanna-Build Team

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'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.

Release Team

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.

UbuntuDiff

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.

Debian France

I am a member and supporter of Debian France, a Debian trusted organization. Under the umbrella of Debian France, I have co-organized mini-Debconfs in Paris in 2010 and 2012.

Other

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.

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.

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.

Gergely Nagy

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 McGovern

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.