draft TPA-RFC-36: establish policy on git repository mirroring, hosting and, ultimately migration from gitolite

We have already started mirroring (gitlab#18 (closed), gitlab#35 (closed)) repositories from gitolite to GitLab. We need to decide how and/or if we will accept such requests in the future, and, in particular, whether we want to host all our git repositories on GitLab in the long term.

If so, we need to come up with a migration plan on how the old repositories on gitolite will "map" to the ones in GitLab. This is particularly complicated by the fact that the namespace established on GitLab does not necessarily reflect the one in use on Gitolite, so we are very likely to have to come up with some rewrite rules to handle those redirections.

But at the very least, we need a plan, and we need it fast, because I am worried this migration will happen organically and we will then have to maintain two git hosting systems in parallel. This is similar to the problem of "hosting both trac and gitlab in parallel" that we have (succesfully, i think) avoided, but it was a near hit. ;)

TL;DR: this is the current state of the non-official policy:

• gitolite and gitweb will eventually be retired, probably in 2022
• new repositories are created on GitLab
• repositories can be mirrored between gitolite and GitLab
• repositories ("only small ones") can be migrated to GitLab as well
• an RFC will be written before the final migration is started, and discussed here

By "small ones", I think we meant "not tor browser",

We need to define the following policies:

1. do we keep gitolite around forever? no. gitolite and gitweb will be replaced by GitLab eventually.
2. if we do, do we keep the old codebase or upgrade? N/A
3. if we do not, when do we retire git-rw (cupani) and gitweb (vineale)? within 1 or 2 years, that is 2021 or 2022
4. if we do not, how do we protect our code against the larger attack surface of GitLab? opened gitlab#81 (closed) for that discussion this roadblock is removed. it's the responsability of teams to implement commit signing or other integrity measures they need.
5. where do people create new git repositories? gitolite or gitlab? new repositories are created on gitlab
6. can people mirror their git repositories from gitolite to gitlab? yes, in a limited way there are known issues with protected branches (gitlab#38 (closed))
7. how do we mirror a repo from gitolite to gitlab? documented, see this section
8. can people migrate their git repositories from gitolite to gitlab? yes, but only small projects right now, documented here, missing support for redirection on clone
9. how do we migrate a repo from gitolite to gitlab? using the migration procedure
10. how do we redirect users from gitolite to gitlab? using the above migration procedure, although there are issues with SSH clones (which don't fire a hook) and HTTP clones need webserver-level redirection

Remaining task list:

• figure out how to do redirections on git clone
• figure out gitweb redirection patterns
• propose a migration plan for retiring the legacy gitolite infrastructure (cupani/git-rw, vineale/gitweb)

Those can be executed in parallel.