[Intel-gfx] RFC: Migration to Gitlab

[Sean Paul]

On Wed, Aug 22, 2018 at 01:44:56PM +0200, Daniel Vetter 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 ...
> 

/me laughs nervously

> - 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.

They can also pull the trees from git://gitlab.fd.o/blah as normal, just need to
give them new pointers once we're stable.

> 
> - 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.

This seems fine to me. Our expansion plans likely aren't big enough to warrant a
separate group.

> 
> 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.

I'm pretty keen on getting this done, so I'll volunteer some cycles if there's
something that needs doing.

Sean

> 
> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Sean Paul, Software Engineer, Google / Chromium OS