Austin, Herbert,

All good with me.  Thanks for working on this.

Some thoughts:

* Which repos are covered here?  Just the ones that used to be on abbott?  That 
is, the ones maintained by GHC HQ?  Better make that clear.

* Does commit permission cover all repos?  If they are just the old GHC HQ 
ones, fine.  If more, it may need to be more granular?

* Can anyone have a repo on  I assume not.

* I have lots of check-out repos.  Each contains lots of .git/config files 
   because of the multi-repo nature of the GHC build system.  It would be
   a pain to have to edit each individually.  Maybe you can tell us a sync-all
   command to update the URL and pushurl configs, once per tree.

* This might be a good moment to clean out our committer list.   I suggest the 
   - Start a wiki page on the GHC Trac for committers.  Maybe a section of
     or maybe a separate page

   - Send email to all existing committers inviting them to 
        * create an entry on the GHC Committers page, saying who they are, where
            they work, and what they work on in GHC
        * reply to you asking for continued commit permission
     Lacking such a reply, you can omit them.  In this way we'll get an up to 

  - Perhaps we should have a convention that no commits in a year means  you 
     commit permission.  You can be reinstated by asking, but it means we don't 
     a list filled with ex-committers.


|  -----Original Message-----
|  From: ghc-devs [] On Behalf Of Austin
|  Seipp
|  Sent: 30 July 2013 10:42
|  To:; Herbert Valerio Riedel
|  Subject: Proposal: Gitolite for repository management
|  Hello all,
|  Recently with the new server move, a few of us have taken
|  roles of administrating the new server infrastructure including
|, containing the GHC repositories. (Previously, the GHC
|  repos were on, 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 more secure and easier to maintain.
|  We have a proposal with preliminary details up here:
|  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 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
|  _______________________________________________
|  ghc-devs mailing list

ghc-devs mailing list

Reply via email to