RFC: Migration to Gitlab

[Daniel Vetter]

Hi all,

I think it's time to brainstorm a bit about the gitlab migration. Basic reasons:

- fd.o admins want to deprecate shell accounts and hand-rolled
infrastructure, because it's a pain to keep secure&updated.

- gitlab will allow us to add committers on our own, greatly
simplifying that process (and offloading that task from fd.o admins).

There's also some more benefits we might want to reap, like better CI
integration for basic build testing - no more "oops didn't build
drm-misc defconfigs" or "sry, forgot make check in maintainer-tools".
But that's all fully optional.

For the full in-depth writeup of everything, see

https://www.fooishbar.org/blog/gitlab-fdo-introduction/

I think now is also a good time, with mesa, xorg, wayland/weston and
others moved, to start thinking about how we'll move drm. There's a
few things to figure out though:

- We probably want to split out maintainer-tools. That would address
the concern that there's 50+ committers to an auto-updating shell
script ...

- We need to figure out how to handle the ACL trickery around drm-tip in gitlab.

- Probably good to stage the migration, with maintainer-tools, igt
leading. That will also make fd.o admins happy, who want to rework
their cloud infrastructure a bit before migrating the big kernel repos
over.

- Figuring out the actual migration - we've been adding a pile of
committers since fd.o LDAP was converted to gitlab once back in
spring. We need to at least figure out how to move the new
accounts/committers.

- Similar, maintainer-tools needs to move. We probably want to move
all the dim maintained kernel repos in one go, to avoid headaches with
double-accounts needed for committers.

- CI, linux-next and everyone else should be fine, since the
cgit/non-ssh paths will keep working (they'll be read-only mirrors).
Need to double-check that with everyone.

- Some organization structure would be good.

https://cgit.freedesktop.org/drm

libdrm won't be part of the gitlab drm group because that's already
moved under mesa (and you can't symlink/mulit-home anymore on gitlab):

https://gitlab.freedesktop.org/mesa/drm

But there's also drm_hwcomposer, which we might want to migrate into
drm too - gitlab requires a containing group, and
drm_hwcomposer/drm_hwcomposer is a bit silly.

Note: Access rights can be done at any level in the hierarchy, the
organization is orthogonal to commit rights.

- Anything else I've forgotten.

A lot of this still needs to be figured out first. As a first step I'm
looking for volunteers who want to join the fun, besides comments and
thoughts on the overall topic of course.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch