About me

Hi, I'm Marc Brockschmidt and was asked to run for DPL.

Not so ancient history

I was born 22 years ago, so there's not too much to tell. I'm currently studying computer science at the RWTH Aachen, planning to finish with my Diploma in the next two years, specialized in software modeling and verification. I'm also working as tutor at the RWTH (a job usually done by students in Germany, unlike other countries) and as a software developer and system administrator for credativ.

Personal Debian stuff

I've started using Debian about 6 years ago and became a Debian developer in 2004. Since then, I have been involved in many parts of Debian. I've started helping out with the New Maintainer process in 2004, in which I've been AM to dozens of people I now meet again in all parts of the projects. I also joined the NM Frontdesk at the beginning of 2005.

Recently, most of my Debian time has been invested into the release team, which I joined in late 2006. This work has brought me into contact with even more maintainers and packages.

Together with Andreas Barth and Martin Zobel-Helas, I am managing a network of hosts used for autobuilding, porting and other Debian-related services. I'm also part of the Debian Gnome and Perl teams (though I'm only seldomly active in the former and haven't been in active in the latter for quite a while due to my other Debian activities). I am also part of the lintian maintainer team and do work on it from time to time.

What I've experienced in Debian

I'm quite happy to say that I still love the Debian community, even after seeing so much of it. Through the community around our distribution, I've met quite a few people I nowadays consider to be friends. This, not the pride of being part of a group of people providing one of the leading operating systems, is the main source of my motivation to continue working on Debian.

In my time, I have seen quite a few conflicts escalate, usually on mail or in IRC and only in a few, sad cases, these problems couldn't be discussed more reasonably in a face to face meeting. We should learn from this observation and perhaps try to emphasize the human component in discussions over modern media like electronic mail - always recite the one effective mantra in these cases: "Remember there are humans on the other side of the screen"

The source of most of the recurring flame wars in Debian has been the performance of some core teams. In my involvement with both the NM process and the release team, I learned to appreciate the amount of work done by these people who are usually flamed down when something takes longer than expected. I agree, and often did so publicly in the past, with the general sentiment that these teams could do a better job, especially in pushing out information about their work, but I have to say that I'm unable to join in in the violent flaming that so often fills our mailing list archives.

The development of tight-knitted groups of friends working together on some issue is normal and the exclusion and lack of communication with the outside is a regular phenomenon in such circumstances. This kind of behavior even gets stronger when the resources of such a group aren't enough to do all the work - it makes the time spent on their work more effective, but at the same time hinders fresh people to help out. This can hardly be solved from the outside - but a start would be to not defame these groups as "evil cabals" hindering the rest of the project out of spite.

Goals

Things that can't be done

Before writing this platform, I had a look at the platforms of the past years and was amazed that nearly everyone talked about "improving communication", usually meaning that flaming shouldn't be allowed. I don't think this is possible - we can hardly replace all involved developers by cuddly stuffed animals. Good software developers have a strong opinion about topics dear to their heart, two good developers usually have two different opinions. Discussion, even bordering on flames, is OK - as long as it leads to a result.

Things that will be done

Distribute information

The "Bits from ..." mails on debian-devel-announce seem to make a lot of people happy, so doing more of those seems like a good idea. This leads back to the problem of people not communicating ... Well, throw these facts and the few scraps of DPL authority together and you get a solution: The DPL or one of his delegates needs to pull the information from some teams and push it out to dda.

Present Debian better

People often need to present Debian to outsiders. For this, we have no common source of material, so let's create one. Possible content:

This data can then be used to plug together the basis for a complete (individual) talk and save everyone a lot of work.

We should also update the flyers usually handed out on conferences, some of them are awfully out of date - and while we are talking about conferences, there's much too learn of other projects, as not only I observed, but also Sam. We should provide informational posters to be put on display on a booth, invest some money to be able to hand out Debian DVDs and make Debian look as accessible to non-hackers as it actually is. Providing the best distribution won't help if we aren't promoting it.

Make backports.org an official Debian service

backports have supplemented the Debian stable releases for quite some time now, their use is widespread under both desktop and server users. We should finally decide on the few missing bits (how to handle bug-tracking, for example) and make it an official Debian service, just like volatile. The change would only be small - not adding it to ftp.debian.org, but starting off with backports.debian.org pointing to backports.org. The current bpo team has done a wonderful job and should of course stay in charge.

Bring cool ideas and bored developers together

As I've written some time ago, we should create a place where developers without time, but with good ideas for new software (extensions) can drop ideas, so that new people can pick them up and implement them. Nowadays, we do this once a year in the Debian Wiki, collecting ideas for the Google Summer of Code. We shouldn't need to wait for such an event.

Make participation for everyone on -devel possible again

debian-devel@lists.debian.org has been a high-traffic list for some time now and many contributors with limited resources don't follow it anymore for exactly this reason. This is bad, as -devel is supposed to be the list reaching all developers. There are two ways to solve this problem: Either split -devel into more than one list, or publish a digest of the most important discussions on a regular basis. Some time ago, Debian Weekly News did exactly this, so we might just need to find people interested in reviving that project.

Make www.debian.org nicer

The website of the Debian project is wonderful - it contains everything you ever wanted to know about Debian (and a few gory details you never wanted to hear about). The only, tiny little problem is that you usually aren't able to find what you need quickly, and if you do, you can never be sure that the data isn't outdated and there exists a more apt information source. This needs to be changed - updating and cleaning up the content on debian.org is far more important than changing the design (which should also be done at some point, for sure).

Be nice to the Debian ecosystem

There are a lot of Debian derivatives, the best-known being Ubuntu. We have seen quite a few discussion which ended in Debian developers flaming Ubuntu for various reasons - this should stop. Our derivatives exist because Debian provides an excellent, free basis. They are successful because Debian provides an excellent, free basis - and they will stay to be around because of that. We need to accept this and try to work closer together with them, wherever it is useful. Duplicating work because we are too proud to accept that is simply a dumb idea.

The DPL's little helpers

The DPL job is quite time-consuming and I don't have much free time. As that's a bad combination, I have planned on delegating quite a few tasks, especially the part of presenting Debian to the rest of the world at conferences. As I haven't had a chance to talk to all people I would like to work with, I won't give out an actual list in this platform.

Some of the goals I listed above don't need to be done by the DPL (or even a full Debian Developer), so I will also try to integrate the efforts of non-DDs.

Rebuttals

Raphaël Hertzog (hertzog)

Raphaël's idea of a small DPL team sounds more reasonable than last year's DPL board proposal, but still leaves me scratching my head - how will tasks be distributed and who is actually allowed to decide. If Raphaël needs to acknowledge every decision before it is published, there is still a bottleneck, while giving three persons the same authority could lead to problem when opinions diverge.

Raphaël (+ his team) and I share some ideas of the project and at least see the same issues that need to be addressed, though we might have a different opinion on how to actually implement solutions. While my time in the release team has robbed me of most of my idealism and has left me a hard (and cynical) core of pragmatism, Raphaël still shows enthusiasm. I have my doubts that attracting new developers will be as easy as he projects, but let's hope for it.

Steve McIntyre (93sam)

Having been aj's second in command is probably Steve's biggest advantage and disadvantage at the same time, but his platform focusses on current issues instead of the dunc-tank PR disaster. He talks about many of the issues touched by Raphaël's and my platform and proposes similar solutions. I agree with most of what he wrote, but his platform lacks some more concrete example of what he would do as DPL.