Debian Voting Information / 2013 / Platforms for Project Leader Candidates / Platform for Lucas Nussbaum

Who I am / past Debian contributions

French, 31 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 are:

Ruby.

I got involved in Debian by maintaining Ruby packages in the pkg-ruby-extras team. I co-maintain 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 have 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 is 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 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 impact is that it is very easy for anyone to develop another service and get it integrated into our existing infrastructure. The negative impact 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.cgi 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-tutorial package) 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).

Misc.

I am marginally active in the Debian Science team. I have been 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).

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

State of Debian; vision and goals

State of the project

The Debian project is internally in a very good shape. Of course, some improvements are always possible, and there are some grey spots, but all our core teams are reasonably functional, we have good internal and external communication, our infrastructure is generally in a good state, there is no foreseeable big Debian crisis. Stefano Zacchiroli played a huge role in achieving that state, and we should all be very thankful for that.

However, I often have the impression that the project is losing momentum, positive energy, and slowing down. It feels like we are living on the benefits of the past. A lot of very cool things happen in the Debian ecosystem, but very often outside the Debian project. It is good to be a solid basis for many innovative derivative distributions, but should we content ourselves with the package supermarket role?

What should Debian be in 5 years?

Debian should aim at reinforcing its position in the center of the Free Software ecosystem. It should be the main active intermediary between upstream projects and final users. Of course, providing a good basis for derivatives is important, because derivatives users are Debian users, even if some of them do not acknowledge that. But we should also aim at reinforcing the visibility and the impact of Debian itself, because the extremely important values we fight for as a project are often neglected by our derivatives.

Yes, that means working on getting some of the cool stuff done by derivatives back in Debian, and creating more Debian products. For example, we have been providing a fairly good rolling release for almost 13 years with testing, but we totally fail at advertising it as something supported and usable by end users. And now that Ubuntu is considering switching to a 2-year cycle + rolling release, they might get all the good press instead of us. Couldn't we work towards addressing different needs and use cases with different products (rolling release, maybe live images), without compromising the quality of our stable releases? I even think that getting more users of testing would increase the quality of our stable releases by having more eyes to find bugs (reminder: the bug reporting rate has been decreasing).

How do we get there?

Foster innovation inside Debian.

We should be more welcoming towards innovation and experiments inside the project. Often, we merely tolerate them, and bureaucracy makes them hard and slow to conduct.

While it's not a DPL's role to decide of the project's directions, if elected, I will encourage (discussion of) innovative ideas, investigate how the project's resources can be used to support them, and advertise experiments. Of course, such experiments need to include success metrics, and the necessary warnings (no long term guarantee that the experiment will continue, no security support, etc.)

Improving Debian accessibility and reduce the barrier to contribution.

While there are more and more Free Software users (and potential contributors), we compete with more and more projects to attract contributors. Many efforts have already been made in that area, but there is still a lot of room for improvement:

• We should improve our developer documentation (I contributed to that area myself by writing a packaging tutorial; I've also been a developers-reference editor). Some teams still lack proper documentation about their work-flows and tools on the wiki.d.o/Teams sub-pages. How can we expect prospective contributors to stay around if the documentation is not up to par? There is also space for consolidation here: for example, we do not really have a single documentation about Git-based packaging work-flows, so each team tends to design its own, slightly different workflow (I started an initiative about that during Debconf'11, though it has been mostly idle since then). This is very bad: from a contributor's perspective, it makes each Debian team look like a separate project.
• We should simplify our development practices by (1) being better at advertising the recommended practices; (2) being faster at implementing them in most packages (it often takes years for a good new practice to reach a majority market share). For example, we should advertise that, unless you know what you are doing (yes, there are good reasons to do things differently): you should use dh; you should maintain your package inside a team, or, if there's no suitable team, use a Git repository in the collab-maint project (and consider looking for co-maintainers). And we should also work on switching existing packages to this model. And document that process properly, but I'm repeating myself.
• We should improve our sponsorship infrastructure (reminder: half of our package maintainers are neither DDs nor DMs): debexpo / mentors.d.n is great, but could gain more features, such as more automated QA tests (builds, piuparts). Also, I see two ways to work against the shortage of reviewing manpower: (1) finally create personal packages archives, so that waiting for reviews becomes slightly less painful; (2) ask non-DD to review packages in a social website manner (that's also a very nice way to learn).
• We should continue to push for collaborative and team maintenance. We should also consider reducing package ownership. While having maintainers that feel very responsible about packages (and are often real experts of those packages) is an important strength of Debian, maintainers should think in terms of packages I currently take care of inside Debian rather than packages I own inside Debian. The current NMU policy (a change I drove back in 2008) is a good basis, but we could use a small cultural shift to be more welcoming to contributions from other contributors. For example, we could generalize the collab-maint security model (= every DD can commit) to more packages repositories.

  However, team maintenance sometimes hide cases where there are no longer any active maintainer in a team. We should also get better at identifying those cases, and adapt our infrastructure and procedures accordingly.

Improve communication with upstream projects.

It is not unusual that maintainers have no contact at all with upstream developers. We should work on creating a working relationship with upstream projects, involving them in the package maintenance when they are willing to, and exporting information about bugs affecting Debian, or patches in the Debian package (improving http://patch-tracker.d.o/).

The above should give you an idea of where I stand. Of course, I'm unlikely to have time to work on much of the above myself (and becoming DPL probably would make it even less likely). But at least you know what I consider the most important, and where I would push.

Role of the DPL and governance model

On governance

I plan to continue the DPL helpers initiative. There are many DDs (including former DPLs!) with great ideas for the project, but many of them can not dedicate a large-enough amount of time to be the DPL. I would like to build a framework allowing them to share the DPL workload and to move forward with their ideas.

The general direction I would like to aim for here is an open team of DDs driving the project, led by the DPL. In the longer term, this could allow to decrease the specific load on the DPL, which would turn into a simple chair for this group. Of course, this must not turn into a cabal, and must not affect Debian's consensus-based decision making processes. Also, to be clear, I do not plan to go in the direction of an institutionalized DPL team during my term: I believe that we need more time to understand how a DPL team, institutionalized or not, can benefit the project, and to evaluate the downsides of an institutionalized DPL team.

On mediation

An important part of the DPL's role is to be a mediator, and to contribute to solving the complex issues that necessarily arise from time to time in any volunteer-based project.

One thing I would like to work on in that context is a project observatory: gather a set of metrics about the project in order to detect problems proactively, and approach people before the problem degenerates into a big crisis. Of course, not everything can be detect using such metrics, and I also plan to use DPL helpers meetings as a way to build a wider view of the project and its growing issues.

I've sometimes had the impression in the past that the DPL was not necessarily the best person to conduct a mediation (because he did not have a (good) personal relationship with the involved DDs, or because he had a good such relationship with only one side). DPL helpers meetings will be great opportunities to find more suited mediators when necessary.

On organization

The organization built by Stefano Zacchiroli over his three terms has proven to work very well. If elected, I will use the same organization, including monthly mails to d-d-a and a private day-to-day log. DPL helpers meetings will be organized on a regular basis (at least every two weeks).

Rebuttals

So, we got three candidates (which I find a bit disappointing -- I enjoyed past campaigns when we had lots of candidates since it results in more ideas for the project). And three quite different platforms.

Moray Allan

Moray's platform provides a great detailed description of how he would behave as a DPL -- or even of how a DPL should behave. I agree with most of it, and will inspire from those guidelines if I am elected.

What I miss the most in Moray's platform is a vision for the project, and his project-wide goals. He provides some historical perspective and his view on the current status, but where would he like the project to go during his term? That is a symptom of our deeper disagreement on the roles of the DPL. Moray's platform and answers on debian-vote@ give the impression that he sees the DPL as a chair role, as an administrator. However, I think that the project now expects the DPL to do more in terms of coordination, of driving the project and of management of its agenda, as Stefano Zacchiroli has been very active and successful in those areas. On that, Moray writes I see DPL coordination in a routine matter as itself a sign of a wider problem that should be addressed..

If elected, I will consider that it is among DPL roles to ensure that project coordination happens. I will leverage the DPL helpers initiative (which I suggested renaming to Debian Driving Force) to create an open group of people interested in pushing the project forward. Of course, this is about opening discussions, proposing new ideas, summarizing the discussions to ensure wide awareness and participation, but not about changing the way the project takes decisions.

Gergely Nagy (algernon)

Only candidate with a nickname, which unfortunately says something about the lack of inspiration of the two other candidates. :)

I agree with most of what Gergely wrote in his platform, e.g. on on the state of the project, on the value of direct communication and local events, and on the need to recruit new contributors.

Something I would have liked to see more in his platform is examples of past achievements in Debian that show where he usually stands, as well as his ability to drive projects. Gergely really has many ideas and willingness to push them forward, but he does not seem to have much experience pushing previous ideas: most of the examples he gives in his platform actually happened outside Debian. It's true that it's hard to acquire such experience in Debian. If elected, I will make sure that the DPL helpers initiative contributes to solving that, by providing an environment where it is easy to receive feedback and advice on pushing ideas forward, and I hope to work together with Gergely in that context.

Back to the Debian Project homepage.