-----BEGIN PGP SIGNED MESSAGE-----
I hereby de-nominate myself as a candidate for DPL 2006.
I have realized this week that there are aspects and parts of the
project that I can't emotionally deal with. Especially abusive behavior
on mailing lists, the vocal support for it, and the persistent
resistance to any attempts to fix it. I thought I had grown a skin thick
enough to deal with it, this past year, but I was wrong. I now find that
I need to be able to ignore parts of the project or be unhappy. This
makes me unsuitable to be the leader.
A few people have encouraged me in public and in private to run for DPL,
and I apologize for letting them down like this. In some ways, I am a
I'm publishing this half-finished draft of my DPL platform in the hopes
that it can be useful in the upcoming debates, or gives food for thought
I'm skipping the part where I praise myself and recount my history in
the project, since that is no longer relevant.
On the whole I think Debian is doing pretty well. We have some problems,
and some of them are on the way of becoming big ones, but it's not too
late to solve them.
Major Goal: Make Debian discussion channels drastically less hostile
This is, I think, perhaps the biggest problem in Debian as of today.
The big, high-volume Debian mailing lists, and to some extent their
corresponding IRC channels, can be quite hostile. Many discussions
become aggressive, and even seemingly innocent technical decisions
turn out to be quite controversial, sometimes due to old grudges.
This is bad for productivity, and bad for quality. It's also bad for
getting new people to join, and for keeping old people. It's bad for
keeping people happy to be part of the project. Many of our developers
avoid debian-devel, debian-project, and debian-legal, for example,
because they find it saps out the fun of working on Debian. Instead of
feeling invigorated and re-motivated after a meeting of minds with
friends, they feel angry, sad, and disappointed.
This needs to be solved some way.
A "code of conduct" has been suggested. We have a vague, really old
one, that is pretty much never enforced. I think we should write a
new one, and make sure the listmasters have the power to enforce it.
Goal: Make all infrastructure jobs delegated or elected
The ftp-master team, the account managers, the system administrators,
and the stable security team, at least, are not officially delegates of
the DPL, or elected by the developers in general. I think this is bad
for the project, in the long run. If the project in general thinks one
of these teams works badly, it needs to be possible to replace or
augment the teams, even against the wishes of the current teams.
I don't care whether they are DPL delegates or whether we should
change the constitution to have elections for them.
I also suspect that we would benefit if more people worked on
infrastructure teams, so that the knowledge needed to do the work
is spread out more.
Major goal: Better transparency for how the project works
One of the lessons[*] Debian has learned is that it is necessary to
keep things open and public. People need to be able to see what goes
on in the project. For the most part, we do this very well: almost
all our mailing lists are open for anyone to read, and they're archived,
but there are some exceptions.
The easiest example is the debian-private mailing list. There are some
discussions that go on in there that really should be in public, even
if they are not the nicest ones. Especially since they are not the
nicest ones. Besides the demotivational factor of a private list, the
privacy of the list is actually not very well protected, these days.
Things leak, and they leak not only to, say, various N-Ms, but also
to spouses and friends.
I'm not so upset about the leaking, but of the uselessness of having
supposedly secret discussions that don't actually need to be secret at
all. Therefore I think debian-private should be abolished. We as a
project do not have, and should not have, things we do or talk that
can't be done in public.
The vacation messages that go to -private are an exception. When we
remove -private (or "if", I should say), creating a new, non-archived
debian-vac list might be a good idea.
I would also like to replace, as much as possible, the firstname.lastname@example.org
address with a debian-project-leader pseudo-package in the bug tracking
system. This would be an additional step in transparency.
The DPL Team
The DPL team was a new idea last year. I think it was a good idea, but
its execution has been lacking. Based on discussions I've had, it seems
to me that it has suffered from the classic case of teamwork: there's a
group that needs to do some things, but the things are not specified
clearly, and nobody is personally responsible for anything.
My solution would be to not have an explicit team, but delegate specific
tasks to specific persons willing to take the tasks. For example,
"hey, Foo, I've been invited to conference X, but can't go, could you go
instead and give a talk along *these* lines?". Or: "Bar, could you draft
a proposal for an update of the DMUP, within four weeks?".
For these kinds of delegations, I think it would be good to have the
task outlined and limited fairly strictly, and to have a deadline.
The deadline is important for making sure things happen eventually.
If a deadline is not met, then we know that more people working on
the thing may be needed, or that something else needs to be done.
I would also be very happy to delegate away as much as possible, because
I'm that kind of lazy.
Major Goal: Speed up development
While preparing this platform, I ran into the following quote:
Another important aspect is dpkg: development there has been close
to non-existant for too long now. There are additions that we really
need, such as a new source format to support multiple patches and
That was written in 1999, by Wicher Akkerman in his DPL platform
(he was elected).
We've had quite a bit of effort put into dpkg since then, but mostly in
maintenance mode. Not a whole lot of new things have been added, and
we've been sorely missing the new source format. For seven years now.
I think it's fair to say that Debian development has slowed down from
its first years. I think this is partly because Debian is so big, both
in number of packages and in number of developers, and that gives a
lot of inertia. When a change needs to be made that affects lots of
packages, it takes a lot of time to get it done. A simple library
transition can take months.
That's not good. We need to come up with ways of doing big changes
faster. I'm not sure how this is best accomplished. Maybe we would
benefit from co-ordinating changes so that when a library transition,
or big policy change, or some other such needs to happen, it is first
tried in a small scale outside the main archive. When the wrinkles
have been ironed out as much as possible, all other uploads to sid
are suspended for a few days, and then the big change is pushed in
as quickly as possible via NMUs done by a dedicated team (and
automated as much as possible).
Or the solution might be something else. I am not married to any one
idea, and we would certainly have to experiment to see which approach
Goal: Internal training
We have a long, tough New Maintainer process, during which we make sure
that the candidates for developership have or learn a variety of skills
related to packaging. After that, we leave it to everyone to develop
their skills as they see fit, and that is good. However, we don't have
a lot of support for self-learning.
Having occasional or regular IRC training sessions, or writing small
tutorials, would be good to keep up the skills of us all. We have some,
but they are not collected in a central place. At every Debconf, a
of talks and tutorials, but not everyone can be there, and anyway, not
all topics fit into the Debconf schedule.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
-----END PGP SIGNATURE-----