On Sat, Nov 17, 2007 at 08:29:52PM +0100, Martin Michlmayr wrote: > * Anthony Towns <[EMAIL PROTECTED]> [2007-11-18 04:48]: > > DAM (and FD, and AMs and nm.debian.org) is a policy position -- it's > > about deciding who's allowed to do what, rather than a technical > > position that involves keeping some software/hardware working; it's > > very subjective and that's about it. Adding more DAMs (or AMs or FD > > members etc) is straightforward. > Actually, it's not straightforward, simply because "deciding who's > allowed to do what" is not straightforward.
There's a big difference between straightforward and easy. Adding DAMs
isn't easy, but it is straightforward:
- find acceptable candidates
- talk to existing members about candidates
- expand team with candidates (or replace existing team members
with candidates)
It's hard because we've got a lot of requirements for "acceptable"
candidates for DAM to meet, which last I knew left our pool of acceptable
candidates at zero. I don't know if anyone's tried running a crash course
in DAMing, like the release assistant stuff [0] in order to create some
candidates, though.
Changing keyring-maint isn't straightforward because we don't really have
a widely agreed upon understanding of what exactly the role actually
entails as distinct from DSA/buildd/ftpmaster/DAM (could keyring-maint
include keys for buildds? exclude DD keys? retire DDs?), but would be
easy to actually do ("hey, Bob, you're keyring-maint now! have fun!").
Adding AMs otoh, is both straightforward and easy. And conversely changing
the n-m process so we don't keep having bottlenecks isn't straightforward,
and even if we knew what was needed probably wouldn't be easy.
Cheers,
aj
[0] http://lists.debian.org/debian-devel-announce/2007/06/msg00007.html
http://lists.debian.org/debian-devel-announce/2005/07/msg00009.html
http://lists.debian.org/debian-devel-announce/2003/03/msg00007.html
signature.asc
Description: Digital signature

