RFC: Migration to Gitlab

[Emil Velikov]

Hi Dan,

On 22 August 2018 at 12:44, 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).
>
Random thought - I really wish the admins spoke early and louder about issues.
>From infra to manpower and adhoc tool maintenance.

> 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.
>
As a observer, allow me to put some ideas. You've mostly covered them
all, my emphasis is to seriously stick with _one_ thing at a time.
Attempting to do multiple things in parallel will end up with
sub-optimal results.

 - (at random point) cleanup the committers list - people who have not
contributed in the last 1 year?
 - setup drm group, copy/migrate accounts - one could even reuse the
existing credentials
 - move git repos to gitlab, the push URL change, cgit mirror
preserves the normal fetch ones as well as PW hooks
 - work out how new accounts are handled - still in bugzilla, otherwise

At this stage only workflow change is a) once-off account setup and b)
pushURL update
As a follow-up one can setup anything fancy.
 - migrate PW/other hooks
 - migrate bugs - if applicable
 - add new hooks - DRM docs, other
 - etc


> - 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.
>
One should be able to create a separate repo for these. And then either:
 - one by one add the required features into the gitlab MR machinery,
 - or, wire the execution in pre/post merge stage.

IIRC there are some upstream requests about the former.

> - 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.
>
It did strike me a lot when drm_hwcomposer/drm_hwcomposer was
introduced. Fortunately moving repos in gitlab is reasonably pain-free


HTH
Emil