Platform for Anthony Towns

Hi. My name is Anthony Towns. I'm running for DPL this year. These are the things I'd like to work on.

Welcoming people to the project

I think it's important that the project accept contributions from an as large and diverse group of technically skilled people as we can manage. I think the best way to achieve this is:

To have our lists filled with interesting technical discussions, that welcome intelligent contributions from new-comers, and don't waste a lot of time going over old ground or off-topic subjects. Further remarks: [1] [2]
To have newcomers be invited to act as assistants to existing groups; and for helpers be treated like individuals, rather than a new build that needs a standardised test suite run over it. Further remarks: [1]
To have users be able to participate in the project in an acknowledged way, and thus able to be consulted on decisions directly, rather than to have their opinions guessed at by developers. Further remarks: [1] [2] [3]
To make our activities far more public, by doing things such as conducting more discussion on existing lists, creating temporary lists for quick discussions that are nevertheless permanently archived within Debian, and summarising discussions over IRC or in person to lists as a matter of routine.
To actively try to include derivatives into the project, rather than passively hoping they'll contribute to us -- such as including projects like Knoppix, backports.org, Ubuntu, fink and others into the archive where possible; and otherwise helping relationships with folks like HP, Linspire, SkoleLinux and others. Further remarks: [1]

Project Effectiveness

Although sometimes it's hard to tell, Debian actually has a purpose: namely to create a great free operating system. It's important for us to be effective in achieving that purpose -- it's no good have the best design for an operating system, or the best policies for putting it together, or the best procedures for maintaining it if we don't ever get around to following the design, policies and procedures and implementing something. I think Debian's been falling behind in this department, and I think the way to resolve that is to work at actually making decisions and standing by them, rather than trying to maintain a fractured consensus by repeatedly having the same debates with new participants.

Our mechanisms for making decisions are:

consensus on the mailing lists
judgement of delegates and maintainers
judgement of the technical ctte
general resolution by the developers as a whole

The first of these has been the key to Debian's success -- any decision that can more or less satisfy everyone in a diverse group is a pretty good one. It's not always possible to make a decision that way, of course; which is why we need the other options. Unfortunately they're not working well at present.

It's my belief that Debian could be improved here simply by giving delegates clear authority to make decisions over their areas of expertise, and accepting that others are expected to persuade or convince delegates and maintainers that something should be done in some particular way. Further remarks: [1]

Additionally, I think that the technical committee would serve the project better if it were composed of active members of key teams, rather than the current membership of wise elders; both as an indication of confidence in our delegates, and to ensure the technical committee's knowledge of Debian's processes is as current and complete as possible. Further remarks: [1]

Distribution Quality

Finally, I think we could produce a substantially better distribution. Much of that work has already been done by derivatives -- such as the init script speedups Ubuntu folks have worked on, or the LiveCD development Knoppix is famous for -- and we can gain those features just be working on better integration with derivatives; but there are other issues that, to my mind, Debian itself should be working on:

Better policy -- at present "policy" is fragmented between debian-policy, the Developers Reference, various subsystem specific documents, and word of mouth. I believe we should work on integrating that into a single package, if not a single document.
Better QA -- having the full source code to all the software we use gives us the chance to excel in a bunch of "QA" type areas; I think we shouldn't just aim at grabbing all the cool software out there and putting it in a .deb, but that we should be filing off the rough edges too, by writing automated test suites for our packages, making sure everything is documented, and working towards zero defects in everything we ship.
Better package selection -- a problem that every Debian user has faced and will probably face again is working out which packages they want installed; do you want ether-wake, or wakeonlan, eg? I think it's long past time we made some consistent progress in this area, addressing issues like package categorisation, package overlap, and accessibility of non-free or commercial packages.

Addenda

So, a couple of other notes, which you might or mightn't find relevant.

I think the role of the DPL is, well, to lead the project: to find particular areas that the project should focus on, and to find areas where the project's being dysfunctional and help it sort itself out. The DPL really only has one power, and that's to give authority to others. That's a fairly subtle power -- it's the difference between someone having the root password and having permission to use it. But in a group of people who care about what's right and wrong as firmly as Debian developers do, it's actually a fairly important power. Further remarks: [1] [2]

For those who care, I joined Debian in early 1998. I'm the author of ifupdown and debootstrap. I've written patches for gzip (#30537, #184057), dpkg (#93386, #112386, #184635), pax (#139943), and others. I've participated in the LSB and FHS forums, and on a variety of Debian lists. I still eagerly await the day when #18733 and #62529 are resolved.

I wrote the CGI scripts for bugs.debian.org as a proof of concept and started preserving old bug reports rather than letting them be lost forever once they'd been closed for a month. I then found myself on the debbugs team when the old scripts that generated the static pages once or twice a day started failing because we just plain had too many bugs. I also added support for bug tags, queries by submitter, cloning bugs, and blocking access to the control@ address for people who abuse it.

My most public activity in the project has been my participation in release management. I started being involved in that in '98 by getting involved in the discussions on -devel about the "Debian release modem" (sic) and along with other interested folks came up with the ideas behind testing. After more discussion and modifications, I started implementing "britney" in 1999 by maintaining a hardlinked copy of the archive, and eventually got to the point where I thought it was ready to start integrating properly in 2000. At that point I offered to help Richard Braakman out with potato's release management, who at that point sensibly fled the country, and I got to do the final phases of potato's release, which came out in August 2000. I then worked with Jason Gunthorpe (who's the primary author of Apt for those playing along at home), and James Troup to get the archive converted to pools so that the horrible hardlinking stuff could be dropped and testing could be mirrored, and we rolled testing out in late 2000. Sometime around this point I was added to the ftpmaster group to make the integration easier. I continued as release manager for woody, at which point I thought it'd be a good idea to follow Richard's fine example, and was lucky enough to have Steve Langasek and Colin Watson volunteer.

I took the opportunity to step down from the release management role last year for a few reasons. The long term reasons were that I'd been looking to pass on the RM role for quite some time -- I'm more interested in (and effective at) initial design and implementation than long term maintenance -- and that Colin and Steve were already at the point where they were doing most of the work anyway. The proximate cause was that I no longer felt confident that I had the project's support to do the RM job, and that Colin and Steve would have a much better opportunity to do that without continuing confusion and distractions. I think that's actually panned out fairly well.

My ftpmaster activity mostly consists of maintenance of britney, design work, with occasional poking at processing new packages and removal requests. I did a fair amount of work coordinating the move of crypto software into main, figuring out how to redo security support for the woody release, and designed and implemented the signed Release files and helped with the apt support thereof.

Conclusion

I think my experiences within Debian match reasonably well with what I'd like to achieve and that some good progress on the above items should be possible over the next year. But hey, I've been wrong before.

Critiques of Alternate Candidates

And hey, these people have been wrong before too!

Rebuttal

Angus Lees

I envy Angus's brevity up to this point, and hope one day to be able to match it.

Matthew Garrett

I think Matthew's platform is pretty good. His priorities are slightly different from mine, but I think if he achieves what he plans, it will be good for Debian.

I do, however, disagree with Matthew's focus on non-confrontational discussion. It's my belief that attempting to avoid confrontation tends to result in trying to satisfy the most argumentative people, since they will tend to ensure there is a confrontation unless they get exactly what they want, whereas quieter people will generally not cause a confrontation until things start becoming seriously unsatisfactory. I do believe it's possible for people to deal with differing opinions and different approaches respectfully, without having an argument, or being rude; but I think it's important for anyone in a leadership position to be ready to stand up for the people working with them, and that means at least the occasional confrontation. I believe it's far better to have those confrontations and resolve them, than it is to avoid them.

Andreas Schuldei / the Scud Project

I find the development of the Scud Project quite disconcerting; it seems to have been a secret group of Debian developers who have gotten together with the specific goal of taking control of the project, and really I'm not sure how something like that could be anything but disconcerting.

Andreas and Steve did all (or at least almost all) of the organising of the release cabal meeting held in Vancouver (on the 5th and 6th of March), which was a great idea and, I think, highly effective -- but it was also organised without the knowledge of the current DPL, let alone with much information being provided to the rest of the project. I like to joke about the cabal in Debian, but that's because in my experience it *is* a joke; all the people in positions of power in Debian have fairly different opinions and do quite happily work against each other, fail to communicate with each other at least as much as with the rest of the project, and have all manner of other problems. The Scud Project by contrast seems to have been an actual "cabal" up to this point, and I'm confused as to how deliberately appointing such a group to lead Debian could be a good thing in promoting the sort of open, public, community-oriented development that Debian's famed for.

Another concern with the Scud Project is that it's not at all clear how it will operate if elected -- whether each member already has well defined areas of authority, or whether the DPL will make the decisions and the team will enact them, or whether they'll try to make decisions as a group with the DPL as a figurehead. It's not clear if that depends on which candidate is elected. It's also not clear how fully the Scud Project supports the platforms of its two candidates, or how fully the candidates support each of the team's members. That seems like it makes it a bit of a crap shoot voting for either candidate from the Scud Project.

Branden Robinson

There's probably not much I can write about Branden that won't be dismissed with something like "Oh, but AJ and Branden fight all the time, of course he'd say that". And if you're into amusing epic archetypes, Branden and I even joined the project in the same week (late February 1998 for those who want to check the -private archive -- also the same week Eric S. Raymond joined).

Anyway, I've two concerns with Branden that you may or may not wish to consider. The first is his consistent focus over his years of campaigning on procedural issues to the exclusion of technical ones: I think it's far more important for members of the project to focus on what we want to achieve rather than how we want to achieve it, and that we're much better off if we screw up the processes occasionally but don't lose sight of what we're trying to achieve, than the converse. I think that should be reflected in the project leader's priorities.

My second concern is that I don't think Branden's demonstrated that he's very effective at achieving his goals. When he became SPI treasurer in August 2001, his aim was to fix the record keeping problems that had accrued up until that point, and become far more transparent and efficient at accepting and processing donations and distributions. Unfortunately, and for various reasons, he didn't manage to achieve this -- to the point where donations to the Debian project over a period of something like a year were not deposited at all, and then expired such that they're unable to be deposited at any point. With Branden's demotion to deputy-treasurer under Jimmy Kaplowitz, he seems to have become dramatically more effective, which speaks well for him, but, to my mind, still indicates he's unready for a significant leadership position. Further remarks: [1]

I feel I should also note that while Branden indicates that Project Scud supports the election method we use at least for the DPL vote, he was one of the few people who voted against its adoption at the time it was proposed; and further argued extensively that it encouraged insincere voting in the lead up to the non-free votes a little over a year ago.

Jonathan Walther

I find I disagree with the sentiment Jonathan notes in his platform of increasing concern related to the involvement of women in Debian. I, personally, have been quite heartened by both the increasing number of women who feel they can participate in Debian, and the form of their participation, in particular Margarita Manterola's magnificent dpkg state diagrams, Hanna Wallach's presentations at Linux conferences, and the mentoring programme being run by Helen Faulkner, as well as the usual range of package maintenance and bug reporting and fixing. TTBOMK, this activity is thanks mostly to the work by Erinn Clark and Helen Faulkner in setting up and maintaining the debian-women project. It's particularly impressive that all these women have made all their contributions to date prior to having successfully passed through the new-maintainer queue.

I think the best thing we can do about women's participation in Debian is admire their accomplishments to date, do what we can to help them improve upon their achievements, and ensure we incorporate their successes into other areas of the project.