Proposal: Gitolite for repository management

[Austin Seipp]

Hello all,

Recently with the new haskell.org server move, a few of us have taken
roles of administrating the new server infrastructure including
ghc.haskell.org, containing the GHC repositories. (Previously, the GHC
repos were on abbot.haskell.org, which was maintained by Galois. The
new servers are community managed.) I'm one of these people, so first
off if you have any problems, let me know!

I should also say Herbert Valerio Riedel has also stepped up to help
administrate the GHC Trac instance. He's quite experienced in these
sorts of matters, and his help is greatly appreciated. If there's
anything wrong in this area, he can also be of help. :)

Anyway, the real topic: Recently, we have been discussing the way
GHC's repositories are managed, and it's slightly suboptimal for
several reasons. We would instead like to deploy Gitolite, a smart
git-access wrapper. This will not only solve some annoying issues
(like Simon's recent permissions error when pushing to testsuite,) but
also make ghc.haskell.org more secure and easier to maintain.

We have a proposal with preliminary details up here:

http://ghc.haskell.org/trac/ghc/wiki/GitolitePlan

Please refer to it for the exact details. But the visible overview for
all the active developers will be:

 * Shell accounts will go away. You'll only have access to the repositories.

 * Your SSH push URL will change very slightly.

 * sync-all will probably need to change a bit for the new remotes.

This will all need to happen within a small window of downtime. As
outlined above, we believe we can pull off a switch with minimal
interruption. So on that end, we need to know a few things too. What
we'd like to know is:

 * Does any developer who has shell access to ghc.haskell.org actually
*need it*? Outside of administrative tasks, I'm not sure who should
and should not have access. At the least, your privileges will be
slightly reduced after we're done (since the darcs group won't be
needed.)

 * Who is an active committer? I'm not really sure what to do here,
but we can easily transplant all the current users in the 'darcs'
group. Alternatively we can establish it for most of the core
committers, and add people who commit less frequently on a rolling
basis (they can just contact me.)

 * When should this be done? The downtime window will be small
hopefully, and I don't think this would really inconvenience anyone
too much if we did it soon, but I feel we should ask.

-- 
Regards,
Austin - PGP: 4096R/0x91384671