General keyring process questions.

Konstantin,

I'm dog-fooding the trusted introducer process with one of the CTI TAC
members as a way to work out the kinks for the general developer
workflow of adding and removing people.

Questions:

- Does adding a key to allowed-signers give access to also update
  allowed-signers itself?

  - The answer I epxect is "No" because I want a distinction between
    community "admin" and community "developer" (which write access
    to the repository).

  - I assume the answer is that only trusted indtroducers can update
    the keyring, and that the keyring is only an intermediary keyring
    because it doesn't look like a normal gitolite admin repo.
    
- What is the syntax of allowed-signers?

  - What does 'namespace="git"' mean?

- Are new account requests sent to [email protected]?

- What are the implications of selecting a username?

  - I assume the answer is that the username is not visible anywhere, but
    is the username used during the ssh connection to the gitolite server
    and as such is the name used in the gitolite admin repo with the keys?

- How do we authorize group membership?

  - How do we know what groups to request in the email to LF IT?

  - Group membership is a gitolite repo policy detail and some groups may
    have distinct project policy e.g. web repo vs. code repo.

    How do we enforce that policy?

    For example, a gitolite project will usually have an admin repo with
    configuration and keys, and the code repos. In the current setup it
    LF IT is the maintainer of the admin repo, and the community maintains
    the keyring and content repos. If we have several content repos, how
    do we authorize only access to one of them? Is that encoded in the
    allowed-signers in some way?

-- 
Cheers,
Carlos.