[igt-dev] RFC: Migration to Gitlab

[Jani Nikula]

On Wed, 22 Aug 2018, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> 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.

Just a couple of concerns from drm/i915 perspective for starters:

- Patchwork integration. I think we'll want to keep patchwork for at
  least intel-gfx etc. for the time being. IIUC the one thing we need is
  some server side hook to update patchwork on git push.

- Sticking to fdo bugzilla and disabling gitlab issues for at least
  drm-intel for the time being. Doing that migration in the same go is a
  bit much I think. Reassignment across bugzilla and gitlab will be an
  issue.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center