[Cryptech Core] git repository usage patterns and access control

[Rob Austein]

Now that we've been using git.cryptech.is for a while, it may be time
to review the current policies encoded in the configuration and decide
whether they still reflect what we want.

To recap the current policies:

- All[*] git.cryptech.is GIT repositories are public read, via HTTP,
  HTTPS, and, for authorized users, via SSH (wold be kind of silly to
  allow HTTP and HTTPS but deny read-only SSH access).

- Authorized users can create new repositories via SSH using gitolite.
  Newly-created repositories are public read, but initially writable
  only for their creator.

- The owner of a repository can grant write access (push access,
  really) to other authorized users via the gitolite "perms" command
  on a per-repository basis.

Last week we had our first case of two developers trying to
collaborate and finding the above policies at least temporarily
inconvenient: problem was resolved when I told them about gitolite's
"perms" command and one of them granted write access to the other.

The question before the group is whether this is the right approach.
Options I can see:

1) Current setup is fine, leave it alone.  If you want somebody else
   to be able to push to your repository, you have to configure it,
   for each and every somebody else and each and every repository.

2) Same as (1), but adopt a github-like work pattern where developers
   who want to hack each other's code fork the repository.  gitolite
   even has some direct support for this:

   $ ssh git at git.cryptech.is fork <repo1> <repo2>

   gitolite does allow authorized users to delete their own
   repositories, but it's tedious enough that I suspect adopting this
   work pattern would result in a clutter of single-use repositories
   that nobody can be bothered to clean up.  Maybe that's OK (ick), or
   maybe there's some stylized way of doing this that would allow us
   to clean up old forks automatically (needs thought).

3) Define some group of authorized users (which would probably be
   called "@pushers" in the gitolite configuration file) which
   automatically gets write access to all repositories.

   Core would have to decide who gets to be in @pushers; one possible
   criterion would be "people who are under contract to write code".

4) Same as (3) but make @pushers an alias for @all, ie, allow any
   authorized user to push to any repository.

5) Another variation on (3), in which the @pushers group exists but
   isn't automatically granted write access to new repositories, the
   repository creator has to do that explictly.  In this variation
   @pushers might be better called @theusualsuspects.

I have no strong feelings about any of this, except that (4) strikes
me as too coarse-grained.  But maybe I'm making this all too complex.

Comments?  Other issues?

[*] Truth in advertising: every use of the term "all repositories"
above excludes the magic "gitolite-admin" repository, which is really
part of the server configuration rather than a code repository.