Steve McIntyre's DPL platform, 2007

Introduction

I've been a Debian Developer since October 1996. I originally joined to maintain the Debian version of mikmod; I was the upstream developer at the time, and wanted the Debian version to work well too. In those days, the NM process was rather simpler than today: I installed Debian, then two days later I mailed Bruce Perens with a PGP key and asked him for a Debian login. He responded almost immediately with account details - I was in!

Since that point, I've worked on quite a wide range of packages, some large and some small. Probably the most noticeable work I've done for Debian is within the debian-cd team, both developing the debian-cd software itself and using that same software to create the official CDs (and now DVDs) that accompany each Debian release. I've been involved with the CDs for almost every major and point release since Hamm.

I stood as a candidate in the DPL election last year, and came second to AJ. Shortly after the election, he contacted me and invited me to take up a new delegated position of Debian "2IC", or Assistant Project Leader. I accepted, and since then I have been helping him with some of the duties of the DPL - dealing with correspondence, representing Debian to the press and at various Free Software gatherings and acting as a mediator in some disputes. This has given me a good insight into the work of the DPL: what it entails and just how much time it can take.

Goals

Much of this platform will be familiar to people, as it is largely based on what I said at this time last year. Most of the things I want to work on in Debian have not changed in that period: they are well known problems, issues that have affected us for a long time.

Communications within the project

This is a long-term bugbear; DPL candidates have been promising to work on improving communication within the project for as long as I can remember. There are several places where communication has been problematic in the past. Sometimes DPL effort has helped to fix things, but more often there has been no visible improvement.

Simple, regular status updates from the various teams within the project can help a great deal here. Equally, regular reports from the DPL are needed to make sure that the Debian community are aware of what is being said and done on their behalf. Even if some of these reports consist purely of "Sorry, I've been busy in real life and not accomplished much", simple confirmation that posts are not sitting unattended is better than nothing. I aim to encourage these updates, and if elected I will commit to distributing regular news from the DPL.

Training and NM

Currently the NM process contains detailed tests of an applicant's technical abilities, and of course this is a good and useful thing to do. Unfortunately, we don't select for social skills; we need to work together as a community!

NMs are often asked to show their skills by constructing a new package and/or taking over an orphaned package. This can be good for testing packaging skills, but can lead to NMs working on packages in which they have no real interest - further down the line these are most likely to be the packages that are abandoned.

I'd like to suggest that more NM training can/should happen more within teams. We have a large number of packages where the maintainers could do with help, and a large number of NMs looking for jobs to do. I believe this is a great place where we can improve. We need some sympathetic maintainers to make this work - they will be responsible for the work done, and then will be expected to report to the relevant AMs. I have already volunteered some of my own packages towards this effort, and I'd like to encourage other DDs to do the same.

We also still need to work out how to more effectively deal with the multiple different types of contributors that we have these days. As well as package maintainers, we have more and more people working in other important areas such as translation. It's well past time that we had an good debate on this topic and settled the issues.

Openness within the project

We promise to be as open as possible, but we often fail on this front. Sometimes this is necessary (e.g. when discussing embargoed security updates), but much of the time it is not. Sometimes discussions are private when they do not need to be, and this is not good for us. Sometimes technical work is done within our various teams and when this work is presented to a wider audience "cabal" accusations are made.

Unfortunately, there is no magic way to improve this situation. I believe a major blocker here is the aggressive attitudes that are often shown in our development forums, and these need to be curtailed first. Once we have a healthier atmosphere for discussion, then more open discussion will happen naturally.

Technical standards

In our large repository of software, we have a very large number of packages and a very large number of maintainers. Most of the work in Debian is done very well, but unfortunately not all of it. Much has been said in the past about our developers being volunteers who cannot be forced to do work that they don't want to. That may excuse people working slowly on their packages, but it does not excuse some of the sloppiness that happens from time to time, for example packages that fail to build on a clean system.

We have a growing number of tools that a maintainer can use to check the quality of their packages (linda, lintian and now piuparts). We have build tools that can reduce the chance of broken dependencies and other build-time issues (sbuild, pbuilder, etc.). Yet we still regularly have broken or low-quality packages uploaded.

There are two issues here, as far as I can see. Some of our maintainers are not aware of updates that have happened to our tools and procedures. Some of us don't feel the need to use those newer tools and methods. Both these issues should be fixable: more documentation on best-practice packaging and testing methods will help, both in describing what's available and why they're good.

Working effectively; asking for help

Continuing on from the previous point: another part of the DD's job is to work effectively, both on our individual packages and within the project as a whole. This includes simple things like handling the bugs in our packages in a timely fashion, but also includes bigger things, such as considering the impact of changes on the release schedule. Working effectively is not just important for our own gratification; it also makes a major impact on how long we take to release and the experience our users have with using Debian.

In my opinion, a key part of working effectively is honesty. We can all suffer from a lack of time to do the jobs that we've promised to do. After all, real life has a nasty habit of intruding on our so-called "spare" time. So long as we don't let things delay too far, we can cope and still contribute. But at some point, we need to be more honest with ourselves and actually admit that we can't continue with the jobs that we've promised to do. It's a hard thing to do, but in a friendly community where we're all working together towards a common goal there should be no shame in asking for help.

In a larger scope, procedures exist for DDs to temporarily leave the project if real life has overtaken them, and re-join when the situation changes. Again, there is no shame in doing this - we should be happy to acknowledge all the contributions that people have made to Free Software when they could. But, still, many people don't take this route and instead simply become missing in action (MIA). It can take quite a while to pick up on DDs who have simply dropped out of the project.

Why vote for me?

We have a large field of candidates this year, which may make it difficult for our developers to decide how to vote. I believe I can do a good job as DPL due to the following qualities:

Summary

I have touched on some issues here that are hopefully not surprising to most of our community. I must also acknowledge the fact that the DPL does not have the power to simply impose changes as he/she sees fit. The best that the DPL can do here is to encourage us to improve, sometimes by discussion and debate and sometimes by leading by example. I don't claim to be perfect, but I believe I can help us to achieve some of the goals I have listed here.

Thanks for your time in reading my platform.

Rebuttals

Up front, I should say that (again) I believe this year we have a selection of good candidates. This is one of the bits of the DPL election process I like least, as I don't believe in being negative about other candidates. Nonetheless, I should put some effort in here. I'd like to be DPL (obviously, otherwise I wouldn't be standing!) but I'd also be happy enough to see any competent person elected. There is a lot of overlap of ideas, I can see. Here are my thoughts on the other candidates and their platforms:

Wouter Verhelst

Wouter is well-known, experienced DD whom I consider a friend. We have met lots of times, at Debconf and FOSDEM meetings amongst others. He talks about wanting to improve the social core of Debian, which is something I agree with and wish him the best of luck with.

Aigars Mahinovs

Aigars is something of a dark horse here, with not much history in Debian that comes to my mind. I must admit that his ideas about release, a "Distribution Trunk" and the "Old Maintainer Process" don't do much for me. On configuration file reform I think he has some useful ideas, but I don't see that as needing DPL work at all. For the record, I agree with him completely on the trademarks front. The whole trademarks idea is a mess!

Gustavo Franco

Gustavo has a huge number of goals listed in his platform, covering just about every area of Debian that I can see: release, core teams, the BTS, NM, New processing and much much more. Good luck with whatever he can achieve out of that big list; I think he'll need it.

Sven Luther

I don't see a platform here.

Sam Hocevar

I had been unimpressed in the last year by Sam's attempts to make humour out of problems in Debian, so I did not expect to see much here. However, his platform does have a lot of positive ideas on how to improve things and I hope he can deliver on some of them.

Raphaël Hertzog

Raphaël has a good history of contributing to Debian, probably most famously for lots of work on Alioth. He and I have worked together in the past, and his suggested goals sound entirely reasonable. His main push is for a DPL board, an idea that I'm not 100% convinced about. Despite that, I have offered to serve on his board in the case he might be elected - after all, the DPL job will still need doing and I'll be happy to help.

Anthony Towns

AJ and I have worked together quite a lot over the last year as DPL and 2IC. It's been very productive, and I thank him for the opportunity to help. He talks this year about technology, community and getting things done, all major topics. I know AJ can deliver on DPL work, and I wish him the best of luck again in the competition this year.

Simon Richter

I'm not sure what to make of Simon's ideas. He lists problems in his platform, but I don't see any proposals on how to fix them.