inamerrata

My first blog post after winning the Debian Project Leader election. Scary. Links so far: debian-project, Slashdot, ZDNet Australia. I’m trying to make sure I’ve got something vaguely new to say before replying to press requests, and to also make sure I say anything new on some Debian forum first, and given there’s one I’m replying to tonight, well, you do the maths…

So my tentative theory is to put together a list of ten-twelve “interesting projects” to push forward over the course of the year, in theory one a month. The idea is that’ll stop me from letting my time be taken up reacting to things — whether that be problems, questions, the press or what have you — and thus losing control of what I’m doing, and that it’ll also force me to keep moving onto new things regularly, and also to actually “finish” them too so they don’t cause an ongoing distraction. My current list of topics is: maintainers; partners; extended suite support; constitutional stuff; non-free; distributed leadership; localisation/specialisation; livecds; the etch release. Those are just heading to roughly remind me of various s3kr1t pl0ts I’ve thought about in the past, and you shouldn’t read too much into it — you’re welcome to think about them yourself, and get inspired though.

And I’m sure I’ll change some of them around over the next few days; but one that won’t include the first one, which is something that I’ve been thinking about for most of the year now. I’ve talked about it privately with a few people over drinks and IRC, and it looks like it’s basically at the point where it seems sensible to everyone, and just needs to be coded up.

But enough teasing.

There are a few ways to explain the concept, this is the one I prefer. The idea is to do away with the whole concept of “sponsored uploads”, and replace it with a more formal and efficient way of doing the same thing. Sponsorship has a few significant problems: first, it makes it harder to work out who’s actually responsible for an upload when you can’t just rely on the name in the changes file; second, it puts a roadblock in the way of getting bugs fixed in the sponsored package — you don’t only have to have the fix ready, you have to find a sponsor with free time to check your work and upload; and third, it confuses who is responsible for broken packages: the sponsor for not doing sufficient checks, or the packagers for not getting it right in the first place.

The obvious way to fix the first problem is to make dak check that the key used to sign the .changes files uploaded actually matches the person listed in the .changes file as doing the uploading. But of course, that alone would kill off sponsorship, and thus make a fairly large number of packages (does anyone know how many?) essentially unmaintained, and also make it harder to prove you know what you’re doing when going through the new-maintainer process.

Interestingly, the obvious way to solve the second and third problems is also to do away with sponsorship, but in a different sense — namely by letting the packager upload directly. Of course, that’s unacceptable per se, since we rely on our uploaders to ensure the quality of their packages, so we need some way of differentiating people we can trust to know what they’re doing, from people we can’t trust or who don’t yet know what they’re doing.

Of course, there’s not really anything stopping us from doing that; and it’s something that’s been suggested before — it just means that as well as separating some contributors to the project out as “Debian Developers” after passing the new-maintainer process, we need some other level of people who’re trusted to do what sponsored packagers currently do — maintain a single package, after getting vetted by a developer.

And basically, that’s what I think we should do; and I’m calling the intermediate level “Debian Maintainers”.

The idea is that while a Debian Developer (DD) can do everything we currently can — upload NEW packages, NMU each others packages, hijack packages in extreme cases, and so forth — a Debian Maintainer (DM) can only maintain a specific package, after being authenticated by a DD in three ways: first to ensure they’re a real person via the usual key signing mechanisms, second to ensure they can be trusted to understand what uploading to Debian involves, and third to ensure that they understand what’s involved in maintaining a particular package before being given rights to upload new versions of that package.

Hrm. This is getting too long, so I’ll leave commenting on implementation details for later, and close with some of the possible implications on how Debian works.

One thing is that it means is that it adds an extra way in which you can contribute to Debian; from just using it, you can move to helping other people in usergroups, to contributing bug reports, to helping fix bug reports, to sending the maintainer patches to upload, to becoming a DM, to becoming a DD.

Another thing it means is that the DAM role becomes somewhat more decentralised; suddenly every DD can vet new contributors, though in a far more limited way than the DAM and FD does.

Another thing is that the utility of being a DD both rises and drops: if you just want to maintain some package, being a DD instead of a DM is pointless; but on the other hand, this is a new ability DD’s don’t currently have. It’s possible that might have a flow-on effect to new-maintainer, meaning that fewer people bother with it — giving AMs more time — or that the people who do bother with it need to be more thoroughly tested, or tested on different areas — giving AMs less time.

Another thing it means is that there’s the possibility of more central control over who can upload than sponsorship allows — rather than only looking at which DD is involved and which package is involved, we’ll have signatures by the person who did the actual packaging directly.

And of course if we have their key anyway, we can — if we choose — allow that key to sign votes in elections, with whatever limitations we might choose, such as requiring they be a registered contributor for over six months before voting, or that their votes are advisory only rather than binding, or that they can only vote in some elections, or that their vote is weighted less than a DD’s vote. And, of course, we could try different arrangements out and see what effect they have.

This is a big thing, so it needs to be done with a great deal of care. In particular, it seems like the best way to handle DMs will be to do so almost entirely automatically (rather than add extra tasks to keyring-maint or the new-maintainer team eg), which means both that the scripts need to be written with extreme care, and probably also that all the information they work with be completely public so that it’s easily auditable.

The current theory is that becoming a DM should work roughly like:

1. work with some developer, by helping resolve bugs, providing or testing patches, and otherwise demonstrate you’re interested and sensible
2. ask that DD to send an advocate mail to a bot supporting your desire to be a DM
3. reply to an automated mail from the bot, indicating you support the social contract, agree with the DMUP and constitution etc
4. receive an acknoledgement from the bot that your replies are in order, that your key is signed by a DD other than your advocate, and that you’re a registered DM
5. ask that DD (or another) to upload a new version of the package you want to (co-)maintan with your name and email address added to the Maintainer: or Uploaders: field
6. maintain the package directly

So that’s the theory. More detailed thoughts on the implementation later, hopefully after I’ve caught up on some sleep.

I debated a bit where to send this — since I expect trying to get this idea happening will be my main focus this month, maybe it would be better off on one of the Debian lists; but on the other hand, it’s a bit more half-baked than I’d feel comfortable posting to -devel-announce, and I suspect just posting to -devel would miss some people it shouldn’t. And hey, it’s not hard to forward a url, or just cut and paste the whole thing, right? Discussion (probably on debian-devel) encouraged.