1 Who I am – past Debian contributions
Incumbent DPL. French, 32 years old, Free Software user since 1997, Assistant professor (Maître de conférences) of Computer Science at Université de Lorraine where I have the chance to teach Free Software and Debian in the context of a system administration curriculum.
I started contributing to Debian in 2005. My main contributions, before my election as Debian Project Leader in 2013, are:
I got involved in Debian by maintaining Ruby packages in the pkg-ruby-extras team. I co-maintained the interpreter packages, and initiated the work on our new packaging helper, gem2deb (= dh-make-ruby + dh_ruby), that makes it much easier to package Ruby software and significantly improved our relations with the upstream community.
- Collaboration with Ubuntu.
I worked on improving ways to manage divergence between Debian and Ubuntu, and to get Ubuntu improvements back into Debian. I contributed to a lot of softening in Debian/Ubuntu relations in the early years, to policies such as the listing of the Ubuntu changes in Ubuntu changelog entries, and added ways to get information about packages in Ubuntu with the Ubuntu box on the Packages Tracking System, and the Ubuntu column in DDPO. (read more: slides from a FOSDEM 2010 talk)
- Archive rebuilds.
I had been rebuilding all packages in Debian on a regular basis since 2006. As a result, I filed over 7000 “FTBFS” release-critical bugs. Yes, I do feel bad about it, but I try to think of it as detecting problems early, not only as delaying releases ;). The same infrastructure was also used to test major migrations or toolchain changes involving gcc, Clang, and Python. (more info: slides from FOSDEM 2007 talk, blog post about the more recent move to AWS)
- Ultimate Debian Database.
Debian services (dak, wanna-build, BTS, DEHS, popcon, lintian, etc.) are very much heterogeneous in terms of technologies and interfaces. The positive consequence is that it is very easy for anyone to develop another service and get it integrated into our existing infrastructure. The negative consequence is that it is very hard to combine data. Ultimate Debian Database solves that by importing all relevant data about Debian (and derivative distributions) into a single SQL database. Several services have been developed on top of UDD (including bugs search and Debian Maintainer Dashboard) and many others rely on UDD as a data source. (more info: paper + slides at MSR’2010; Debconf’09 talk)
- Debian packaging tutorial.
I wrote a packaging tutorial (
packaging-tutorialpackage) to provide a more accessible documentation for prospective maintainers. I used it to teach Debian packaging on a few occasions, and it has been translated into French, German and Spanish. It is also a nice way to advocate good practices, such as packaging with dh (slide 26), or first steps to get involved in Debian (get involved in teams / adopt existing packages, but not package more useless software when better alternatives already exist in Debian; slide 42).
I was marginally active in the Debian Science team. I have been an application manager in the NM process. On a few occasions, I also summarized huge threads on debian-devel@ (e.g. on rolling, and on forced orphaning of packages).
(An overview of my first term as the DPL is provided in section 3.3.1 below.)
Overall, most of my Debian contributions aim at addressing problems at the distribution scale (QA, data-mining), and at enhancing collaboration and communication (with new contributors, with derivative distributions).
2 State of Debian – vision and general goals
Debian and distributions in general are probably at an important point of their history. After being the focus of a lot of attention for a long time, this focus is moving to other areas of the Free Software world. Of course, it does not mean that Debian is dying. It probably means that distributions have mostly solved the problems they were initially working on, and are now perceived as off-the-shelf components that just work.
What should the Debian project do about that? Two things: get better at what we are already doing, and work on addressing additional important challenges of the Free Software world.
2.1 Get better at what we are already doing
Debian is at the center of the Free Software ecosystem. It is the main active intermediary between upstream projects developing more than 20,000 pieces of Free Software and final users. It provides integration and robustness to the Free Software world. Those are great achievements, really, especially given the volunteer-based and community-driven nature of Debian. Also, Debian’s adoption and popularity are probably at its historical maximum: a lot of people care about what Debian is going, as shown by the coverage of the init system debates. But can we do better? Probably.
In the post-Snowden world, we should improve the trustworthiness of our packages archive thanks to reproducible builds and binary-throw-away uploads (not using the binary package built on the Developer machine as the one that goes to the archive). We should improve the quality of our packages using more automated testing, using existing tools as well as the ci.debian.net infrastructure.
We should also continue to work on being a more welcoming project, both for our upstreams, for our derivatives, and for prospective contributors of all kinds. Debian is often perceived as an organization that is hard to grasp on both organizational (teams), technical (practices) and social sides. There are great initiatives such as Patch Tracker, Derivatives Front Desk, Debian Contributors or the Debian Code of Conduct, but there’s a lot more to do to enable easier collaboration with individuals and organizations (e.g.; improving/simplifying development practices and documentation, developing mentoring initiatives, reactivating the quite dormant debian-companies@ initiative).
2.2 Address additional important challenges, the Debian way
Our role in the Free Software ecosystem should extend beyond being a solid distribution for others to base on: we should use our existing position and expertise to contribute to solving additional important challenges. Doing things the Debian way also increases the visibility and impact of Debian itself, and thus of the important values for which we fight for as a project.
First, we should leverage Debian’s current status to improve the Free Software ecosystem as a whole. One good example is the Debile project (website currently down, slides available) that aims at performing Quality Assurance tests on the Debian archive: this contributes to improving the QA tools, the tested software (compilers, toolchain), and after fixing the detected problems, Debian. But we could go further, and imagine providing upstream library developers with an easy way to test candidate changes on all reverse-dependencies in Debian.
Over the recent years, there has been a huge growth in the size of the typical stacks involved in infrastructure software (think of beasts like Cloud or virtualization stacks). They usually include dozens of intertwined packages, that often must all be configured in a specific way to work together. Our typical solutions to handle the configuration of packages work well for a single package, but are less suited to jointly configure several interacting packages. That’s where configuration management tools generally excel, even if the large number of competing such tools shows that there’s no final answer to that question yet. How can distributions help facilitate the distribution of complex software stacks?
A lot of usage is moving from traditional platforms (laptops, workstations, servers) to tablets and smartphones. That’s a world where free operating systems, especially Debian-based, are rather scarce. Of course, a major blocker is the limited availability of hardware platforms that don’t require patched kernels or non-free software. But there’s still a long path before we will be able to run Debian on all our computers, from smartphones to servers.
Addressing those challenges requires the project to be more welcoming towards innovation and experiments, even when they are only at the stage of half-baked prototypes. Often, we merely tolerate such experiments instead of encouraging them, judging them too early, which makes conducting them inside Debian harder and slower than necessary. We should also provide infrastructure to support those experiments, such as unofficial developer repositories (PPAs).
3 Goals for a new term
3.1 Looking back at my current term
Becoming the DPL is like switching jobs. You discover that reality is a bit different from your expectations, and you get to learn a lot of stuff. There are really two sides to the role of the DPL. One is being an administrator of the project, making sure that the project stays in good shape, and smoothing the issues that make Debian frustrating. That involves many small tasks, but just to outline a few: I helped grow the Trademark team, which then initiated the registration of the Debian logo as a trademark. I revoked all old and inactive delegations to create a clear picture of current delegates (with the help of Moray Allan). I defined criteria for the evaluation of prospective Trusted Organizations (with the help of auditors and DPL helpers).
The other side of the role is to push forward and work on projects that are particularly important for Debian. For example, I did a survey of new (packaging) contributors in order to better identify the main hurdles that one has to overcome when first contributing to Debian. Some resulting ideas are still to be implemented, but one main result was that, after a discussion with Asheesh Laroia at DebConf, I developed how-can-i-help, a simple helper to highlight opportunities for contributing to Debian in locally-installed packages (featured in this bits.d.o post).
Also, even if that’s really a minor contribution, I’m quite proud to have proposed the idea and a prototype implementation for important/key packages, that evolved into something part of the automated removal of RC-buggy non-key packages, which I hope will help reduce the duration of the next freeze.
There’s a lot more, of course, as described in my day-to-day log (
master:/srv/leader/news/bits-from-the-DPL.txt.*), and in my regular Bits from the DPL (04 05 06 07 08 09 10 11 12+01 01+02). Additionally, to increase the insight about what the DPL does and plans to do, I also made (most of) my TO-DO list public, and included it in my monthly reports, which I consider a nice step towards more transparency.
3.2 Why am I running for re-election?
That decision has not been easy to make. As I have already mentioned in the past, the workload involved in being the DPL is just huge. I was not expecting it to be light of course, but it was worse than I imagined: I know that if I do not spend 1.5 to 2 full days working on Debian per week, my backlog tends to increase. I must also admit that I feel quite hacking-deprived: I would love to be able to spend more time on technical stuff.
But then, there are many more reasons to run again.
The first one is that it’s about Debian, of course. We should all be very proud of what we are building together. I feel very honored to play such a role in such a great community. You are all great, really.
Another reason is that I learned a lot of things during that year as the DPL, and it would not feel quite fair for me to leave now, without first giving back a bit more. There are some things which did not go perfectly well, too, and I’d love to have an opportunity to do better.
Finally, it seems that the init system debates are approaching an end (or at least I hope so). After those very difficult times for the project, I think that some stability could be useful, especially as we are in the middle of a release cycle.
3.3 Specific plans for a new term
If re-elected for an additional term, I would of course continue on the same path as during my first term (also applying the lessons learned from the things that did not work so well during that first term). However, there are also two specific areas where I plan to put a special focus.
3.3.1 Building a better understanding of Debian’s financial status
The status of Debian’s available resources, and of Debian’s annual budget, are a much more fuzzy status than we would like. As a result, questions such as Can we afford to spend $amount on $project? are very hard to answer. Together with the auditors team and our Trusted Organizations, I plan to work on improving the tracking of our revenues and our expenses, so that it is possible to build an annual Debian budget, at least approximate. There are other upcoming tasks in that area, such as improving our overall donations infrastructure, and our reimbursement processes. The expected outcome is that, by working on those issues now, we will facilitate making a lot of money-related processes and decisions later: use Debian’s financial resources to sponsor more sprints, buy better infrastructure, solve problems that cannot be solved in another way.
3.3.2 Achieving sustainable governance in Debian
Our current model for Debian governance does not scale well, something that was also noted by e.g. Stefano Zacchiroli during his DPL talk at DC12 (slides 22+23). It requires finding someone who can dedicate a large amount of time to Debian during a full year, which restricts the set of possible candidates. The ideal DPL also would have a very diverse set of knowledge and skills (technical, accounting, legal, management) that are almost impossible to find in a single individual, but could be found inside a team.
Various options have been proposed and sometimes tried over time: DPL team, second-in-charge, DPL helpers, etc. The DPL helpers initiative provided useful help with some issues, but was also disappointing on some aspects: (1) the amount of participating people was rather low (several meetings with two or three participants, which prompted me to stop organizing them since the beginning of 2014); (2) I don’t think that it provided much more insight about the DPL’s tasks to participants; (3) its setup prevented it to help with some aspects of the DPL role – for example, some behind-the-scenes discussions could have been helpful to get early feedback on ways to address specific issues, but that’s difficult to do in a public discussion channel.
I plan to try a different variation of the DPL helpers idea, that could be summarized as a rolling board: I plan to share private DPL information (such as email sent to leader@) with a set of Developers active on tasks from the DPL TO-DO list, and use that group as an advisory board to discuss issues and ideas before they can be discussed in a wider audience. I believe that this would be a solution for: (1) sharing the DPL workload; (2) increasing the awareness of DPL activities among possible future DPL candidates; (3) getting more feedback early, resulting in better decisions; (4) enabling participating in DPL activities from people who are unable to dedicate enough time to run for DPL themselves.
Of course, there is the risk of creating a cabal, and of reducing transparency. I am absolutely committed to avoiding that. As an initial implementation, I would justify every month (probably as a note in the day-to-day log) who is part of that board based on activity during the previous month. In terms of privacy, the members of the board would receive emails sent to leader@, and an additional alias (leader-private@) could be created for information that should not be shared with the board. I am also committed to maintaining the same level of information about the DPL’s activities (day-to-day log, monthly bits emails). I would also like to point out that many of our core teams have private discussion channels (mailing lists or IRC), and that the private nature of this experiment is mainly a way to officialize what already happens when the DPL decides to include someone relevant in a non-public discussion, or consult someone in a private IRC discussion. In some sense, DPL helpers and the board would be similar to the public/private discussion channels of our core teams.
Of course, there are lots of other things that I would like to see happen (see this page for a list – some of them would require more discussion first). And I would surely work on them if I end up having the time. But after one term as the DPL, I believe that the two areas described earlier (better understanding of Debian’s financial status; sustainable governance) are really a must to provide a more easily manageable project for the future.
4.1 Neil McGovern
Neil's platform shows a lot of experience and skills in many areas of Debian. This does not cover all skills needed for a DPL, but that's probably unavoidable - I was in the same position a year ago. That's something that my DPL board proposal could contribute to addressing, by providing first-hand experience with DPL tasks to prospective DPL candidates.
I agree with Neil's vision of the current status of the project (Where we are now). I also agree with him that we should aim at remaining relevant to the community, and that our software should continue to integrate, as he writes in . But as I wrote, I think that, additionally, we should also address non-technical challenges (e.g. becoming a more welcoming project) in addition to those technical challenges, and that we should also work on other new challenges that we are not really addressing yet (see sec. 2.2 of my platform). In other words: continue to do what we are good at (what both Neil and myself agree on, obviously), but also bring some more fun by working on new important & difficult challenges of the Free Software world, where our expertise as a distribution could be valuable.
The more specific plans (How I will help get us there) outlined in Neil's platform are important, although some of them are not very specific, unfortunately - I would have liked to see more about how, if elected as DPL, he planned to work on those plans. For example, There's a large agreement that some parts of our infrastructure should be modernized (including adding PPAs), but that's super-difficult, and surely takes more than pushing.