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:
do we keep gitolite around forever? no. gitolite and gitweb will be replaced by GitLab eventually.
if we do, do we keep the old codebase or upgrade? N/A
if we do not, when do we retire git-rw (cupani) and gitweb (vineale)? within 1 or 2 years, that is 2021 or 2022
if we do not, how do we protect our code against the larger attack surface of GitLab? opened gitlab#81 (closed) for that discussionthis roadblock is removed. it's the responsability of teams to implement commit signing or other integrity measures they need.
where do people create new git repositories? gitolite or gitlab? new repositories are created on gitlab
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))
how do we mirror a repo from gitolite to gitlab? documented, see this section
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
how do we migrate a repo from gitolite to gitlab? using the migration procedure
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
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.