Anthony Towns: The second half...
Continuing from where we left off…
The lower bound for me becoming a DD was 8th Feb ‘98 when I applied;
for comparison, the upper bound as best I can make out was 23rd Feb,
when I would have received this mail through the debian-private list:
Resent-Date: 23 Feb 1998 18:18:57 -0000
From: Martin Schulze
To: Debian Private
Subject: New accepted maintainers
Hi folks,
I wish you a pleasant beginning of the week. Here are the first good
news of the week (probably).
This is the weekly progress report about new-maintainers. These people
have been accepted as new maintainer for Debian GNU/Linux within the
last week.
[...]
Anthony Towns <ajt@debian.org>
Anthony is going to package the personal proxy from
distributed.net - we don't have the source... He may adopt the
transproxy package, too.
Regards,
Joey
I never did adopt transproxy – apparently Adam Heath started fixing
bugs in it a few days later anyway, and it was later taken over by Bernd
Eckenfels (ifconfig upstream!) who’s maintained it ever since. Obviously I
did do other things instead, which brings us back to where we left off…
- Crypto in main: It’s getting hard to remember the days when strong
crypto software was classed as munitions and even getting a web browser
to do SSL properly was a legal challenge; but for a long while that’s
how it was, and as a result we had to keep all our security tools hosted
separately to our main, US-based archive. The laws for that changed
in early 2000, introducing a new exemption to the prohibition for
software whose source code was available royalty-free (I think they
called it “public source”). Unfortunately there were still drawbacks:
it wouldn’t apply to some stuff in non-free, it wasn’t clear how far
you had to go with the source code (is libssl’s source enough, or do you
need the source for the apps that use ssl too?), and the biggest problem
was you had to notify the export bureau and the NSA for everything you
wanted to distribute.
And all of that’s couched in the sort of confusing language you’d
expect to find in, well, export regulations. So we ended up getting
nowhere on merging crypto into the main archive for a long while because
we couldn’t be confident of what we actually needed to do. We’d more
or less already missed the opportunity to do the merge for the potato
(2.2) release because it was frozen more or less exactly when the new
regulations came out, and according to my mail archives Ben Collins
(DPL at the time) got a team organised to review the legal issues by
mid-May 2001.
By July 2001, though, we still weren’t really getting anywhere; the
lawyer we were talking to was looking at the ENC exception (which was for
closed source stuff, and requires an active review by the BXA), instead
of the TSU exception (which just requires notification). While it wasn’t
terrible legal advice – following the ENC exception had a lower risk
of misunderstandings on our part leading to problems later – it wasn’t
useful in achieving our aims, ie, getting crypto stuff into main with
a minimal level of ongoing effort, as well as a minimal level of risk.
So moving onto August, we’d moved on from the lawyer we’d been using
for this and other issues, to talking to a lawyer who specialised in
export issues (and whose time was being covered by HP). That actually got
us somewhere, with the end results being a matter of public record – we
got the advice we wanted by November, we got a new incoming
system so we could make sure we didn’t publish anything we hadn’t
advised the NSA and BXA about, and most of all, we got cryptographic
software in main for woody’s release. ssh at standard priority,
apt by default checking archive signatures before downloading code to run
as root, iceweasel coping with https:// urls out of the box all suddenly
became possible, rather than artificially blocked due to pointless legal
constraints. Yay!
The way we notified BXA/NSA was somewhat interesting – we ended
up notifying once for each package, when it passed through NEW: which
is easy to automate, and limits the amount of software we block from
review by other developers as best we can. OTOH, it also means a lot
of notifications: the initial notification was a huge box of paper that
got faxed off (there should be pictures somewhere on the net, but I don’t
know where), and the vague hope that the ongoing reporting would not only
comply with the regs, but manage to be something of a denial-of-service
by compliance. As it turns out it apparently got noticed, with the following
mail arriving in September 2005:
(The mails have always been sent with Ben's name attached) That mail was followed by another suggesting a phone conversation; unfortunately nobody seemed to notice the mail, at least until a year later (to the day!) when Joerg pointed out he was getting bounces form the BXA email address we'd been using... (Since then, based on the above mail, we've been recording notifications, but not passing them on; I sent a reply to the mails above indicating that, but didn't receive a response. There's been about 5000 notifications since then)From: Encryption Date: Fri, 23 Sep 2005 12:51:02 -0400 Subject: Addition to Debian Source Code updates Dear Mr. Collins, Your diligent reporting of updates to the Debian source code to the Bureau of Industry and Security has been an excellent example of perspicacity. However, you no longer need to do so per the following update to the EAR: [...]
- Security and the architecture explosion: with crypto-in-main out of the way, along with lots of RC bug squashing, woody was looking good to come out in April or May, but unfortunately that all fell apart because of a lack of automation for handling security updates. Taking a step back, woody managed to introduce five new architectures compared to the previous release -- HP's pets, hppa and ia64; the IBM mainfram arch, s390, and the SGI/embedded mips and mipsel chips. That came just short of doubling our supported architectures (which had been i386, m68k, alpha, arm, sparc and powerpc), and was working really impressively well: testing was watching that they kept in sync, and the buildd network was keeping them all up to date with the latest source uploads, and the toolchain maintainers were making sure new kernels and compilers didn't cause massive breakages. It was great fun to be a part of, and I'm not sure how much is just blurry memories, but from here, it sure feels like it was a golden age on that score... Anyway, all the extra architectures freaked the security team out, given they were already having to worry about ssh'ing to half a dozen machines and manually do builds, and fix them when they broke, and to deal with that there'd been plans afoot for "rbuilder" to get rolled out, which never actually happened. All of which means it escalated from being the security team's problem, to a problem for everyone, particularly the release manager... The result of which meant knuckling down and coming up with a new security build infrastructure, which involved doing a dak install for the security archive, then building on the changes just rolled out for crypto-in-main to allow for packages to be autobuilt before actually being included in the archive, then updating official buildds for all the various architectures to target stable-security and testing-security and prioritise them and upload to the right place. But as stressful and last minute as that was, at least it worked, and woody made it out the door on July 20th 2002 -- and it's a good thing it worked, given woody ended up getting security support until June 30th 2006 -- the usual year after it's successor is released -- for four years support. (The same rule applied to sarge has resulted in two years and ten months' security support; eighteen month release cycles in general should result in two years and six months of support) Since then, with security managed by dak, there's been a few more bits I've been involved in. The most interesting of which (to my mind) was splitting the security upload queue from being completely secret and restricted to folks who are allowed to access updates prior to public announcement, into separate secret and non-secret queues. That was December 2005, and since then we've gone from having Joey Schulze basically being the sole person doing security updates to two separate teams, with ten new members. It's not without it's problems -- particularly for packages that get (mis)classified as NEW, or that get lost on their way for inclusion in the next stable point update, but it's nevertheless lightyears from where we were in April 2002, or even November 2005.
- Playing other people for suckers: with woody released,
the whole "redo to release process" thing was essentially done -- it had
been implemented, it had worked all the way to getting a release out,
and in a fair few respects had improved things. Instead of the eight
months of hand-approved uploads for the potato freeze, things had gone
it automatically, albeit with gradually stricter constraints, right
up until April; and even when the security problems delayed things,
the manual updates only lasted a bit under three months. So at that
point I was pretty happy, and looking forward to making things work a
bit better and basically passing the buck to someone else.
The first bit of buck passing that worked exceptionally well was
jumping on Colin Watson, who'd been offering some debbugs patches on
IRC, and after a delightfully brief discussion with some of the other
debbugs folks, got getting him added to the group and able to make
changes directly on the site. His advogato post the next day was:
Yesterday I was invited onto the group that administers the Debian bug tracking system. I can't decide whether to be intimidated or excited. There's a great deal to do: my first couple of major projects look set to be integrating some of the existing QA interfaces to release-critical bug tracking, and developing a tool to help us edit spam out of bug histories.
There's a lot to be said for grabbing people at the point where they're still intimidated by what they're joining; sure there's a definite risk that they'll break something you'll have to clean up, but that's pretty easy to deal with, and well worth all the extra excitement and energy that comes with a little bit of nerves. I did a talk on debbugs a few years later, at the 2005 DebConf, at which point we managed to entice Pascal Hakim and Don Armstrong into signing up, if I'm remembering right. At the same time Colin rolled out his implementation of version tracking support for debbugs (which I'd specced up a while ago, and helped design, but cannily avoided actually coding). Shortly after, Pasc put together bug subscriptions, and these days Don's pretty much the primary maintainer of debbugs. How cool is that? Passing on release managership was a bit less fortuitous though; it's a big job, and it's not something that you can offer "patches" for, generally. So after a bit of cogitating on just how to do it, I went with an open recruitment call in March 2003, and then a bunch of practical assignments to get the volunteers used to what RM work actually entailed and to see whether they actually like it. The recruitment call was mostly focussed on all the negatives, half to avoid people volunteering to be RM for the power (to decide which release policy wins, to tell maintainers what to do, to drop packages, or to just decide what name/number the next release gets) instead of wanting to actually do the work to get the next release out and keep developers happy; and the other half was the theory that if you make a job look hard, technical, but not terribly risky, it starts looking interesting to the right kind of people. The assignments generally were two parters -- first to introduce some stuff about release management that they mightn't be familiar with, and the second a bunch of problems that needed resolving that'd use those skills. The first set was RC bug fixing, followed by working out why packages aren't getting into testing, followed by dealing with packages with mutual dependencies and removing packages. At some point that evolved into the testing scripts accepting "hints" from the release team as to what packages to try in combination, or which packages to force out of testing. That turned out pretty successful, with Steve Langasek, Colin Watson and Joey Hess becoming official release assistants in August, and Colin and Steve replacing me as RM in mid-2004. It was also pretty satisfying to see Andi Barth do some more release assistant recruiting in 2005 following much the same model, and indeed using much of my mail verbatim. You can't really ask for better than that, I figure.
I speculate that most of what we do for Debian squares with what
others do for their respective distro. Thus, it should be possible
to identify a conceptual workflow applicable to all distros,
consolidate individual workflows on a per-package basis, and profit
from each other. Jonathan let me have the after-afternoon-coffee
slot of the 