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

Re: Question for all candidates: handle debian-admin more openly

On Tue, Mar 07, 2006 at 10:56:57PM +0100, Martin Zobel-Helas wrote:
> There is no way at the moment to see any progress of the issues in public.
> Now my question:
> 1.) Do you think it would be a good idea to handle debian-admin more
>     openly? 
> 2.) Would you encourage debian-admin to do so? If yes, how?
> 3.) Do you think more DSA are needed?

I tend to think "throw more people at the problem" and "be more open"
are easy answers that are rarely enough to actually solve the problem.

At the moment there are a whole bunch of responsibilities interlinked with
DSA. As well as just being root on all Debian boxes, it also involves
setting up and maintaining porter boxes, maintaining services that
there isn't a separate team for (such as wiki.debian.org), maintaining
the ldap database, and is the first port of call for adding people to
infrastructure maintenance teams.

But in all, I don't think there's a problem here, and I don't think
treating it as one is productive.

Which isn't to say there can't be improvements. I haven't been in a
position to do anything about them, so I haven't asked what ideas the
current DSA team have -- which would be the obvious first step -- but
some of the ideas I think would be worth exploring:

    * recruiting people to manage otherwise-unmaintained services

    * letting service admins maintain the machines those services run on
      (giving root@bugs.debian.org to bugs.d.o maintainers, eg -- this
      probably means having more machines dedicated to a single service,
      or setting up Xen or similar, however, both of which have their own

    * splitting LDAP maintenance into its own team, separate to DSA or DAM
      (this likewise has its own difficulties, since at present this would
      give anyone the LDAP maintainers the abilitiy to practically override
      either DSA or DAM in a fairly inauditable and unaccountable way)

    * having better fault tracking for machine-specific problems (both for
      current problems, and historical ones)


Attachment: signature.asc
Description: Digital signature

Reply to: