Hey all,
I've been delaying this mail for a while now, because I haven't been able
to work out a way of writing it that doesn't strike me as not treating
some of the concerns I've heard seriously enough. I still haven't come
up with a way of avoiding that unfortunately, but it seems better to
get something happening, even if it isn't really good enough.
I'm trying to be descriptive here rather than prescriptive or proscriptive
-- we've got a DPL campaign coming up where there'll be plenty of time
to talk about various ways of improving things, so to me the most useful
thing to do now seems to be providing a good understanding of how things
are at the moment, and have an informed discussion over the next few
weeks, rather than a repeat of all the arguments we've already had.
So the first thing I'd like to note is that despite all the criticisms
there are of things like new-maintainer, buildd administration,
ftpmaster, system administration, and whatever else, objectively all
of those areas are very impressive: compared to other distributions,
we still have a huge number of contributors, we still support a huge
number of architectures at an amazing level of quality, we still have
a huge number of packages that are maintained at an amazingly high
quality, we have a huge number of services that are administered in an
incredibly open manner with a pretty impressive level of uptime. None
of that means we can't or shouldn't be doing better, but I think it's
worth recognising that when we say we're not doing a good enough job,
*we* are still the ones setting and raising the bar.
Okay, this is going to get really long, so if you've read this far and
don't really care about any of the above areas, now's the time to skip
to the next message and get on with your life.
I think a good step is to cover what rights some of the more controversial
roles actually have, as best I understand it. Again, this is just meant
to be a description of what is, not necessarily what I think things
should be, or was originally intended or anything else.
* Debian Account Manager(s) (DAM)
- Joerg Jaspert and James Troup
- delegated authority to determine who is a developer
- may only exercise this authority in cooperation with keyring-maint
- have created assisting roles in the form of FrontDesk and
Application Manager
- nm.debian.org documents current progress of active applications
- numerous amounts of documentation and sample reports around for
what form applications should take
* Debian System Administration (DSA)
- James Troup, Martin Schulze (Joey), Ryan Murray, Phil Hands
- delegated authority to determine official Debian services via delegation of
debian.org subdomains
- delegated authority to determine unofficial Debian services via delegation
of debian.net subdomains
- default administrators (root@) for machines donated to Debian
- have created db.debian.org for tracking machines and accounts
and controlling debian.net subdomains
- listed as group "adm" on DSA adminned machines
- have a repository for customised packages at
deb-src http://db.debian.org/ debian-admin/
* System admin for <host> (root@<host>)
- determined by owner/sponsor of hardware/bandwidth
- responsible for security of machine
- determines who is allowed access to host
- determines what services are provided by host
* Debian Archive Maintainer(s) (ftpmaster)
- Ryan Murray, James Troup, Anthony Towns
- responsible for maintianing the archive on ftp-master.debian.org
- determines what may be accepted into the archive
- determines the process by which software is accepted into the archive
- listed as group "debadmin" on DSA adminned machines, have access to
role user "dak" on DSA adminned machines
- assisted by Joerg Jaspert, Jeroen van Wolffelaar, Randall Donald,
Michael Beattie
- ftpmaster and assistants are listed as group ftpteam on DSA
adminned machines
- maintain various bits of information about how the archive is
administered at http://ftp-master.debian.org/ and have a
developer-accessible mirror of the archive software on merkel.debian.org
- BTS psuedopackage is http://bugs.debian.org/ftp.debian.org
* Debian Kerying Maintainer (keyring-maint)
- James Troup
- responsible for maintaining the keyring containing public keys for
all developers as used by DSA for db.debian.org, ftpmaster for the
archive and others
- provides http://keyring.debian.org/ interface to the keyring
- maintains debian-keyring package
- listed as group "keyring" on DSA adminned machines
- assisted in the past by Michael Beattie
- some procedures documented in section 3.2 of the developers reference
and at http://keyring.debian.org/replacing_keys.html
* Buildds...
* Local admin of buildd
- as per other root@ roles
* Debian Buildd Administrator
- Ryan Murray
- maintains buildd.debian.org (wanna-build, wanna-peruse)
infrastructure
- ensures buildd machines are up to date in cooperation
with local admins
- with cooperation of DSA, manages access to wanna-build
* Build log signer(s)
- Ryan Murray, LaMont Jones, James Troup, Bastian Blank and others
- also includes security team for security uploads
- responsible for ensuring builds are uploaded regularly
- responsible for ensuring builds pass basic sanity checks
- must be able to assure themselves that the build machines they're
signing for are secure
- needs to be authorised by buildd local admin to upload
- needs to be authorised by ftpmaster to be accepted into the archive
* Wanna-build access
- Ryan Murray, Steve Langasek, James Troup, Anthony Towns, others
- schedule give-backs, binNMUs, etc
- listed as group "wb-$arch" on DSA adminned machines (amd64
included in wb-i386, mipsel included in wb-mips)
That's intended to be exhaustive and authoritative, but probably
misses some bits that I'm not familiar with or that simply slipped
my mind. That particularly applies to the buildd stuff, which I'm not
really very familiar with, and have generally tried to avoid looking
into in any depth.
In my opinion the only roles that have any "DPL delegation" part are the
ones I've described as "delegated authority" above -- ie, DAM's ability
to determine who's a Debian developer, and DSA's management of the
debian.org and debian.net domains. That opinion's not universally held,
though, and reasonable arguments as to whether other bits of the above
should be considered delegated could be made, and you could also question
whether there's any moral right for the DPL to claim control over those
couple of bits, when it's been other people who've been putting in the
work for years. I'm not interested in having that debate, so please feel
free to consider the above an official delegation or endorsement of each
of the above from me (as current DPL) in so far as that removes the need
to argue over form rather than function.
I'm not going to try to do a NPOV listing of problems that various
people see in all these roles. That would probably be a useful thing
to have, I'm just worried that I'd accidently leave some issue out and
that would be misinterpreted as meaning that issue isn't important,
or is less important than the ones I happen to remember.
Instead, I'll just talk about a few of the problems I'm familiar with,
and some of the ways they're being worked on behind the scenes, so that
that can be taken into account in future discussion.
A major complaint for many of the roles is often summed up in a single
word as "communication". Particular examples are when someone finds a
problem that needs fixing, but the knowledge of that problem's existance
doesn't make it all the way to the people that need to solve it; or when
the information that whatever it is is fixed doesn't make it's way back
to whoever reported the problem; or where people in general don't have
an idea of what these tasks actually involve, and hence are unable to
estimate what requests are likely to be easy or hard, or what actions
on their part might make their requests easier to deal with, or what
they might be able to do to help in general.
One of the causes for that is that role addresses remain the main way
of contacting people -- which means there's no tracking of issues, and
usually a lot of spam to wade through before even finding real requests in
the first place. For some roles, having a pseudopackage on bugs.debian.org
has worked reasonably well, however that's considered unsuitable for some
of the roles due to it's lack of privacy features (in the event that
DSA need to deal with sponsorship or security issues, or keyring-maint
is given personal information as part of keyring updates, eg) and that
the BTS is optimised for the workflow for package maintenance, which is
often a bad fit for some of the above roles.
DSA have been planning on addressing this by setting up an RT install for
use by at least themselves and keyring-maint, and possibly also for buildd
issues. This has largely been waiting on having a DSA-adminned machine
of sufficient capacity set up. That's been delayed for quite a while,
largely in preference to higher priority tasks including upgrading and
rehosting ftp-master.debian.org, upgrading bugs.debian.org, and dealing
with security issues and such as they arise. My understanding is that
the recent shift of bugs.debian.org from "spohr" to "rietz" has managed
to deal with the remaining task with a higher priority than setting up rt
(ie, upgrading bugs.d.o) and has freed up a sufficiently capable machine
(spohr) that rt can be installed on.
Beyond that, many of the queries, particularly for keyring-maint and
buildd issues, are ones that end up better dealt with by an explanation of
what the right way for the requester to deal with the problem is, rather
than the action actually being requested. One of the possibilities that
James Troup has mentioned in dealing with that is to have other people
acting as a first pass to deal with requests that don't actually require
action, and passing on the rest to a different mail alias, that's not
public and (hopefully) doesn't receive any spam either. That's likely
something that will become fairly easy to have happen when rt is setup,
so will probably wait until then.
To the best of my knowledge there's not currently any activity in
collecting any of the existing public information about those roles
or activities into more accessible documentation, beyond the regular
maintenance of the developers-reference package.
A more immediate concern for many people are the current delays in
the new-maintainer process at the "waiting for DAM approval stage",
in particular the "waiting for the DAM to create their account" stage.
This step involves two main activities -- the addition of an entry into
the db.debian.org LDAP database for the new maintainer, and the addition
of the maintainer's key into the keyring. The LDAP entry can only be
added by DSA members, and the key can only be added by keyring-maint,
and both these updates are only able to be made after the new-maintainer
process is complete and one of the DAMs has approved the application.
What this means in practice is that while Joerg Jaspert does a significant
majority of the DAM's task of reviewing applications and ensuring they
meet the appropriate standards, having his decisions take effect is
reliant on his co-DAM, James Troup, taking on his role as keyring-maint
and DSA member to finish the process. And while there are other DSA
members who could assist with the account creation and LDAP entry,
James is the only person able to update the keyring.
The primary reason why there's only one keyring-maint is the "binary
blob" problem: the keyring is a large chunk of 1's and 0's that cannot
be easily validated by a human directly, and doesn't have "source" that
can be easily validated either. As a consequence, if you have two people
working on the keyring, and one hands the other a new version claiming
that the only change is to include a new key for "foo", it's very hard
for the other maintainer to verify those are the only changes being made,
or why they're being made if someone asks later. This also makes it hard
to validate NMUs, and furthermore passing around unverifiable data over
the network adds an attack vector that's difficult to track. It also
makes it hard for an individual maintainer to check that the tools are
doing what they're supposed to be doing.
That's a technical issue, however -- one that seems like it should be
emminently solvable. Ensuring that any such solution is written in a way
that encourages auditability (of the code, of the input and of the output)
is an important part though, and I don't know that anyone even has a good
understanding of how that would be achieved. That probably means someone
needs to try to implement it, and then we can see what doesn't work.
This issue has been mentioned briefly in the past a few times, but to
the best of my knowledge, no one's taken up the challenge so far.
(FWIW, as a quick prototype, after downloading keys of everyone who has
a login on gluck via db.debian.org into "username.key" files, the command:
for a in `ls --sort=s *.key`; do
gpg --no-auto-check-trustdb --no-default-keyring \
--keyring ./TESTRING.gpg --import < $a 2>/dev/null;
echo $a;
done
takes about 14m to run on my iBook G4. So it /ought/ to be possible
to build something that constructs a keyring from source files in a
reasonable amount of time. The resulting keyring is about 19MB fwiw.)
As I've said, the above is my understanding of things, and while I've
tried for accuracy, that doesn't mean there aren't errors. In particular,
the above is based on conversations with the people involved both recently
and in the past, and shouldn't be taken as an official report from any
of them because it's almost certain that new issues have popped up in
the meantime, that I've missed or forgotten some of the blockers or
other high priority issues, and that I didn't know or didn't think of
some of the resources available.
On a personal note, in my experience the most effective way of working
with James and Ryan is to trust that they generally know what they're
doing and more or less leave them to get on with making things better on
their own rather than hassling them for status reports or similar. "Just
leave them to their own devices" isn't something you'll see recommended
in management books, but when people are doing stuff that they care
about for fun, it's worth considering. A downside is that it makes it
hard to know how to help, and the only way I've seen to deal with that
is to pay attention to the occassional mentions of things that might be
appreciated and dive into them. YMMV of course.
That's pretty much the reason I haven't been poking into any of these
areas over the past year -- it's not simply that I trust that the folks
involved know what they're doing and are dedicated to Debian's goals;
but it's also that I think they contribute /better/ if they aren't
closely supervised. I think that's seen some results over the past
year, including much improved spam protection for debian.org addresses,
some neat improvements to the buildd website on both the backend and
the frontend, and a new and much faster ftp-master along with two
dinstall/britney runs a day, among other things.
I guess ultimately, I'm hoping that the rt stuff will make it easier to
retain that sort of "hands off" approach where it's useful while still
making it easy to see what's going on and where there are problems.
Well, that was absurdly long. Sorry. If it's any consolation, it's taken
me a lot longer to prepare and write this mail than it took you to read
it. :(
As far as what Debian's interested in doing about changing any of
the above, I figure that'll form part of the election debates anyway,
especially given they're only a couple of days away now.
Cheers,
aj
--
Anthony Towns
Debian Project Leader
Attachment:
signature.asc
Description: Digital signature