[RFC] glibc and gitolite permission modelling

[Carlos O'Donell]

Developers,

I've been working on gitolite permission modelling for the conversion from git
to gitolite over the past several weeks, and a few key questions have arisen
that could do with some consideration.

As the model has been coming together I have several open questions.

1. Identifier to use for the account.

e.g. Add Carlos O'Donell to the list of maintainers
"@maintainers = carlos"

The simplest answer is to use the sourceware account name as the unique
identifier in the permission mapping model.

Notes: The name itself is only visible in the gitolite admin repository
which by default is not publicly visible, but it will be visible to the
GNU Project maintainers for the project who will have access to repo to
add and remove people.

This can be changed at any point in the future since this is just
an identifier that is associated with an ssh key for access.

I don't see any other unique identifier that we can use right away?

2. Mapping account identifier to commit email.

I want to provide a mechanism for project maintainers or developers to
actively query when their key may be disabled due to lack of activity.

One way to do that is to ensure we have a mapping between "commit author"
and "account" and then a script can be run on the git repo to compute
an answer like:

"In X days your key with write access will be disabled due to inactivity."

~~~
# carlos = carlos@redhat.com
# carlos = codonell@redhat.com
# carlos = carlos_odonell@mentor.com
# carlos = carlos@codesourcery.com
# carlos = carlos@systemhalted.org
@maintainers = carlos
~~~

Note: The roles your account has are not affected, you still retain all
the rights of your role, but your key's access may be disabled due to
inactivity.

Should the mapping be stored somewhere in git and actively updated only
by anyone that has enabled write access to the project? The precedent
here is the gcc MAINTAINERS file which contains current email, and this
would be simpler but contain the history of contribution identifiers.

3. Mapping access to keys and showing proof of access.

If a user determines that their access is about to expire they can
commit an update to a "glibc-access" repository to indicate they are
still in control of the key. The "glibc-access" git commit log will be
used in conjunction with the repository to determine activity.

Is this a useful model or have other projects done something different?

Adding more services to the "is active" list doesn't consider that what
is active and relevant is the key and proving access to the key should
be part of the activity.

4. Initially Read-only branches.

We have 215 user branches which would initially be marked read-only
for anonymous access, and eventually transition to marked read-write
for the owning user and read-only for anonymous.

The reasoning behind this is that we may wish to switch to gitolite's
"personal branch" model where we define "users/[username]/*" as the
place where users can create, control, and share their own branches.

We could leave the existing branches as legacy read-only and let
developers copy into their personal namespace?

Note: Grouping under a path is required, that is to say for gitolite
it must be "[path]/USER/[restricting regex]" and at least one user
in glibc has used "users/[account name]/" to create branches which
seemed sensible.

-- 
Cheers,
Carlos.