So, sometime over the past few weeks I clocked up ten years as a Debian developer:
Apparently that also means I’ve clocked up ten and a half years as a Debian user; I think my previous two years of Linux (mid-95 to mid-97) were split between Slackware and Red Hat, though I couldn’t say for sure at this point. There’s already been a few other grand ten-year reviews, such as Joey Hess’s twenty-part serial, or LWN’s week-by-week review, or ONLamp’s interview with Bruce Perens, Eric Raymond and Michael Tiemann on ten years of “open source”. I don’t think I’m going to try matching that sort of depth though, so here are some of my highlights (after the break).From: Anthony Towns <firstname.lastname@example.org> Subject: Wannabe maintainer. Date: Sun, 8 Feb 1998 18:35:28 +1000 (EST) To: email@example.com Hello world, I'd like to become a debian maintainer. I'd like an account on master, and for it to be subscribed to the debian-private list. My preferred login on master would have been aj, but as that's taken ajt or atowns would be great. I've run a debian system at home for half a year, and a system at work for about two months. I've run Linux for two and a half years at home, two years at work. I've been active in my local linux users' group for just over a year. I've written a few programs, and am part way through packaging the distributed.net personal proxy for Debian (pending approval for non-free distribution from distributed.net). I've read the Debian Social Contract. My PGP public key is attached, and also available as <http://azure.humbug.org.au/~aj/aj_key.asc>. If there's anything more you need to know, please email me. Thanks in advance. Cheers, aj -- Anthony Towns <firstname.lastname@example.org> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. PGP encrypted mail preferred. On Netscape GPLing their browser: How can you trust a browser that ANYONE can hack? For the secure choice, choose Microsoft.'' -- <email@example.com> in a comment on slashdot.org
- Starting small: my first package was distributed-net-pproxy, which would claim a bunch of work units which could then be distributed over the local LAN. Useful if you’re in Australia in the mid-90s and being charged by the minute for Internet access. distributed.net didn’t allow general distribution, so I asked for (and received) explicit permission to include it in Debian. (distributed.net had a ten year anniversary last year too)
- Diving straight in: I got sucked in to the mailing lists pretty quickly, and within a couple of months was up to my neck trying to redesign the way we did releases; oddly enough that didn’t turn out quite so easy, but at least it ended up with some concrete proposals within a couple of months, pretty much synchronously with the hamm (2.0) release going out (and, I guess, about a year after I’d started using Debian…). At around the same time was, I think, my first recorded comment about trade offs regarding freeness…
- cruft: My first bit of Debian specific code was cruft (that its name, not it’s value…), which worked okay as a prototype, but got snagged up in debian-policy trying to get packages to make a note of files they’ll put on the system without telling dpkg (eg, /etc/passwd, /var/cache/apt/archives/*.deb, etc). That pretty much sapped my interest in it, and cruft stagnated until Marcin Owsiany picked it up in 2005.
- Played for a sucker, part one: a few months later I was messing around
doing QA stuff and fixing bugs and as part of that did an NMU of netbase
(which at the time directly contained all sorts of important tools like
ping and inetd directly). That went something like:
From: Anthony Towns Date: Sat, Nov 21, 1998 There are a few bugs accumulating against the netbase package which you're maintaining. I was wondering if you'd mind if I made an NMU to fix some of them for the upcoming slink release?
From: Peter Tobias Date: Sat, Nov 21, 1998 No, please go ahead ... I'm quite busy right now and I would really appreciate any help. Please let me know if you need additional information about the package.
From: Anthony Towns Date: Sun, Dec 6, 1998 There's an NMU sitting in Incoming now. It fixes a few bugs, viz: [...]
From: Peter Tobias Date: Fri, Dec 25, 1998 due to my current job I don't have much time to work on my debian packages. In order to have more time for my other debian packages I would like to give away the netbase package. Are you interested in maintaining this package?
From: Anthony Towns Date: Fri, Dec 25, 1998 Ummm. Sure. I guess. (or, iow, *Eeeeeeeeeeeeek*!!!)
- ifupdown: As part of maintaining netbase I tried to figure out a way of fixing bugs like 31745 and 39118. Basically, Debian used to do networking by generating a script on install that you could modify by hand, and that was it – so when the commands needed changed between 2.0 and 2.2 (no more “route add -net”), you couldn’t make that upgrade “just work”. Red Hat handled it with “ifup” and “ifdown” commands that would look at a whole bunch of shell-format variables in /etc, which worked but wasn’t elegant, so I came up with something I thought was actually pleasant. It’s fundamental attitude is to be a parser – the networking commands are specifed as compile-time configuration, the description of your network is your runtime configuration, and ifupdown just puts those all together without trying to actually understand what’s going on. To some degree, that works really well – it keeps all the knowledge separate so when you’re writing an /etc/network/interfaces, you’re not worried about how DHCP works; in others it breaks down – in particular if bringing up an interface fails part way through, is it up, or down, or something else entirely?
- bugs.debian.org: I’m not entirely sure why, but in August ‘99 I
decided to start running a script to stop old bugs from being permanently
From: Anthony Towns Subject: BTS and old bugs Date: Tue, 24 Aug 1999 22:33:16 +1000 To: firstname.lastname@example.org ObPrivate: Erm. I'm not sure. It is only even vaguely relevant to developers. Since bugs #9705 and #36727 don't seem like being fixed any time soon and Darren hasn't managed to convert the BTS to using debbugs.deb yet, I've made a little script to stop us from continuing to lose bug reports, and am running it in my crontab on master. ~ajt/debian-bugs/archive/ contains hardlinked copies of the bugs in ~iwj/debian-bugs/spool/db (except split into sub-directories). When the bugs get expired from the BTS, the hardlink in ~ajt remains, so the file doesn't get lost forever. In the week or so I've been running it, some 500 odd bugs expired .
- testing: So a year and a bit later and there had been some more discussions about making major changes to our release process, and since I’d done some more algorithms subjects at university by this point, dove in a bit more seriously. For me, the main challenge seemed to be keeping dependencies consistent, and it turns out validating dependencies and conflicts is an NP-complete problem, and solving that reasonably efficiently seemed like a good first step. By October ‘99 I’d come up with a first pass solution, which I think was still in Perl at the time. A couple more rounds of playing with consistency checking stuff ensued, resulting in some regularly updated lists being generated by December, and by March 2000 or so that had graduated to a simulation of testing as we know and love it today.
- Played for a sucker, part two: so after a few months of maintaining a testing suite while potato (Debian 2.2) was getting finalised for release I figured it’d be useful to get broader release experience, so asked Richard Braakman if I could help out with the last bits of the potato release. At which point he said “sure”, gave me James Troup’s email address for accepting/rejecting packages etc, then buzzed off to a mobile phone related junket in the US, and laid low until the release was actually out… A cunning plan, for sure. Happily, that didn’t take too long – I think I started around June, and potato was finished baking for release at LinuxWorld Expo in August, though it did involve about 2000 lines of archive changes and stuff mailed to James over the period, along with half a dozen mails to -devel-announce.
- Junket: In the middle of that was my first ever debconf – or technically the Debian portion of the 2000 LSM/RMLL in Bordeaux, aka Debconf 0. It was awesome – met heaps of cool people, got to practice my high school French, and enjoy some lovely red wine while gossipping about free software. Also heard RMS sing the free software song live. But the wine was great!
- katie/dak: The biggest problem with the “simulation of testing” mentioned above was it was held together with paperclips and sticky-tape; or less metaphorically, shell one-liners and hardlinks. Since packages would originally get uploaded to unstable, and then move into testing, and then get deleted from unstable, you’d end up at least doubling the bandwidth required to mirror Debian, because each package would get sent to mirrors once for unstable and once for testing. Which is fine for a simulation, but for deployment, well, we needed package pools, which in turned required a rewrite of dinstall. James did all the initial work, apart from some of the schema design and the scarier SQL, and by November had it deployed for the non-US archive, and got it onto ftp-master in December. At which point the time was ripe for hooking up testing into the archive proper, which is about the point that the testing scripts got named “britney” so as to fit in with all silly names in the da-katie suite. I’m pretty sure the rationale was that I did the final coordination of the potato release (archive changes, cd images, announcement, etc), I spent from about 3am to 10am listening to a handful of Britney Spears songs on repeat. The phrase “scarred for life” might come to mind. Since that point, there’s been lots of evolutionary changes to both dak and testing (including a rewrite of the perl parts of testing into python), but it’s all built fairly naturally from that point.
- debootstrap: I’m pretty sure my motivation for writing debootstrap was a mix of just wanting to avoid having to worry about out of date base tarballs for the purposes of keeping testing in-sync, and wondering if it was actually possible to write a script to bootstrap a Debian system from the sort of minimally functioanl environment the installer has to put up with. In the end, it turned out pretty cool – it was used by the final boot-floppies, it’s part of d-i, it makes tools like pbuilder possible, I think it helps embedded folks heaps, it’s spawned some imitators, and generally been a pretty cool exercise in hackery.
- Freedom and purity: About six months earlier, there was a big flamewar and an attempted vote on whether to remove non-free from the archive. I’d written a rebuttal and counter-proposal, but it all ended up collapsing in a heap, due to disputes about the constitution. For some reason I feel like this mail was more interesting than all the previous ones combined… That ended up needing a whole bunch of changes to the constitution: one to make it clear under what circumstances the social contract can be changed, and another on what happens when one option on a vote requires a supermajority while another doesn’t, and working that out ended up taking from October 2000 until October 2003. It was actually kind-of interesting; trying to analyse a good voting system that works in the real world has all sorts of interesting maths to it, and there’s a whole bunch of election methods guys that have studied it in a bunch of depth. And since its elections, you can have fun with all sorts of scenarious of corruption – like what if the secretary’s trying to change the results. In practice, the difference between good and bad election methods seems to turn out to be negligible, but why wouldn’t you have the best one you possibly can? A couple of months after those changes were done, dropping non-free got reproposed, and I did another counter-proposal; this time they were actually voted on, with the counter-proposal winning, by a little under a two-to-one margin. Which means we get to get rid of non-free by making it completely superfluous, rather than just near enough.