So, sometime over the past few weeks I clocked up ten years as a Debian developer:<\/p>\n
\n\nFrom: Anthony Towns <aj@humbug.org.au>\nSubject: Wannabe maintainer.\nDate: Sun, 8 Feb 1998 18:35:28 +1000 (EST)\nTo: new-maintainer@debian.org\n\nHello world,\n\nI'd like to become a debian maintainer.\n\nI'd like an account on master, and for it to be subscribed to the\ndebian-private list.\n\nMy preferred login on master would have been aj, but as that's taken\najt or atowns would be great.\n\nI've run a debian system at home for half a year, and a system at work\nfor about two months. I've run Linux for two and a half years at home,\ntwo years at work. I've been active in my local linux users' group for\njust over a year. I've written a few programs, and am part way through\npackaging the distributed.net personal proxy for Debian (pending\napproval for non-free distribution from distributed.net).\n\nI've read the Debian Social Contract.\n\nMy PGP public key is attached, and also available as\n<http:\/\/azure.humbug.org.au\/~aj\/aj_key.asc>.\n\nIf there's anything more you need to know, please email me.\n\nThanks in advance.\n\nCheers,\naj\n\n-- \nAnthony Towns <aj@humbug.org.au> <http:\/\/azure.humbug.org.au\/~aj\/>\nI don't speak for anyone save myself. PGP encrypted mail preferred.\n\nOn Netscape GPLing their browser: ``How can you trust a browser that\nANYONE can hack? For the secure choice, choose Microsoft.''\n -- <oryx@pobox.com> in a comment on slashdot.org\n<\/pre>\n<\/blockquote>\nApparently 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.<\/p>\n
There’s already been a few other grand ten-year reviews, such as Joey Hess’s twenty-part serial<\/a>, or LWN’s week-by-week review<\/a>, or ONLamp’s interview with Bruce Perens, Eric Raymond and Michael Tiemann<\/a> 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). <\/p>\n
\n
- \n
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<\/a> last year too)<\/p>\n<\/li>\n
- \n
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<\/a>; oddly enough that didn’t turn out quite so easy, but at least it ended up with some<\/a> concrete<\/a> proposals<\/a> 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<\/a> about trade offs regarding freeness…<\/p>\n<\/li>\n
- \n
cruft: My first bit of Debian specific code was cruft<\/a> (that its name, not it’s value…), which worked okay as a prototype, but got snagged up in debian-policy<\/a> 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.<\/p>\n<\/li>\n
- \n
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:<\/p>\n
\n\nFrom: Anthony Towns<\/i>\nDate: Sat, Nov 21, 1998<\/i>\nThere are a few bugs accumulating against the netbase package which\nyou're maintaining. I was wondering if you'd mind if I made an NMU\nto fix some of them for the upcoming slink release?\n<\/pre>\n<\/blockquote>\n\n\nFrom: Peter Tobias<\/i>\nDate: Sat, Nov 21, 1998<\/i>\nNo, please go ahead ... I'm quite busy right now and I would really\nappreciate any help. Please let me know if you need additional information\nabout the package.\n<\/pre>\n<\/blockquote>\n\n\nFrom: Anthony Towns<\/i>\nDate: Sun, Dec 6, 1998<\/i>\nThere's an NMU sitting in Incoming now. It fixes a few bugs, viz:\n[...]<\/i>\n<\/pre>\n<\/blockquote>\n\n\nFrom: Peter Tobias<\/i>\nDate: Fri, Dec 25, 1998<\/i>\ndue to my current job I don't have much time to work on my debian\npackages. In order to have more time for my other debian packages\nI would like to give away the netbase package. Are you interested\nin maintaining this package?\n<\/pre>\n<\/blockquote>\n\n\nFrom: Anthony Towns<\/i>\nDate: Fri, Dec 25, 1998<\/i>\nUmmm. Sure. I guess. (or, iow, *Eeeeeeeeeeeeek*!!!)
\n<\/pre>\n<\/blockquote>\n<\/li>\n- \n
ifupdown: As part of maintaining netbase I tried to figure out a way of fixing bugs like 31745<\/a> and 39118<\/a>. 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<\/a>. 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?<\/p>\n<\/li>\n
- \n
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 deleted:<\/p>\n
\n\nFrom: Anthony Towns\nSubject: BTS and old bugs\nDate: Tue, 24 Aug 1999 22:33:16 +1000\nTo: debian-private@lists.debian.org\n\nObPrivate: Erm. I'm not sure. It is only even vaguely relevant to\ndevelopers.\n\nSince bugs #9705 and #36727 don't seem like being fixed any time soon\nand Darren hasn't managed to convert the BTS to using debbugs.deb yet,\nI've made a little script to stop us from continuing to lose bug\nreports, and am running it in my crontab on master.\n\n~ajt\/debian-bugs\/archive\/ contains hardlinked copies of the bugs in\n~iwj\/debian-bugs\/spool\/db (except split into sub-directories). When\nthe bugs get expired from the BTS, the hardlink in ~ajt remains, so\nthe file doesn't get lost forever.\n\nIn the week or so I've been running it, some 500 odd bugs expired [0].\n<\/pre>\n<\/blockquote>\nNext month I sent Darren Benham a first version of bugreport.cgi, and at some point around then must’ve sent off a pkreport.cgi too; by the month after (October) I’d evidently been added to the debbugs group, because I was merging my archived bugs into the official debbugs directories.<\/p>\n<\/li>\n
- \n
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<\/a>, and solving that reasonably efficiently seemed like a good first step. By October ’99 I’d come up with a first pass solution<\/a>, which I think was still in Perl at the time. A couple<\/a> more<\/a> rounds<\/a> of playing with consistency checking stuff ensued, resulting in some regularly updated lists being generated<\/a> by December, and by March 2000 or so that had graduated to a simulation of testing<\/a> as we know and love it today.<\/p>\n<\/li>\n
- \n
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<\/a> with<\/a> half<\/a> a<\/a> dozen<\/a> mails<\/a> to<\/a> -devel-announce<\/a>.<\/p>\n<\/li>\n
- \n
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!<\/p>\n<\/li>\n
- \n
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<\/a>.<\/p>\n
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<\/a>, and got it onto ftp-master in December<\/a>. At which point the time was ripe for hooking up testing into the archive proper<\/a>, 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.<\/p>\n
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.<\/p>\n<\/li>\n
- \n
debootstrap: I’m pretty sure my motivation for writing debootstrap<\/a> 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<\/a> imitators<\/a>, and generally been a pretty cool exercise in hackery.<\/p>\n<\/li>\n
- \n
Freedom and purity: About six months earlier, there was a big flamewar and an attempted vote<\/a> on whether to remove non-free from the archive. I’d written a rebuttal<\/a> and counter-proposal<\/a>, but it all ended up collapsing in a heap<\/a>, due to disputes about the constitution. For some reason I feel like this mail<\/a> was more interesting than all the previous ones combined…<\/p>\n
That ended up needing a whole bunch of changes<\/a> 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<\/a>. 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?<\/p>\n