[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Ideas about a GR to fix the DAM

On Sat, Nov 17, 2007 at 08:29:52PM +0100, Martin Michlmayr wrote:
> * Anthony Towns <aj@azure.humbug.org.au> [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.


[0] http://lists.debian.org/debian-devel-announce/2007/06/msg00007.html

Attachment: signature.asc
Description: Digital signature

Reply to: