[PATCH] Migrate to Gitlab

[Daniel Stone]

Hi.

On Tue, 28 Aug 2018 at 20:31, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> - Use the https url so we don't require everyone to have their gitlab
>   accounts ready already. Otherwise we'd need to gate migrating
>   maintainer-tools on migrating all the drm kernel repos, and I'd
>   really like to partition the migration. Also, we want to reduce
>   maintainer-tools committers anyway, to shrink the attack surface a
>   lot.
>
>   Committers need to either set up the http access tokens, or set up
>   ssh certificates and change their remote for the maintainer-tools
>   repo.

Worth noting for bonus points that GitLab has an audit trail of every
change made to a repo, which our old hosting does not.

> - For testing, you can undo this auto-update using
>
> $ git remote remove maintainer-tools ; git branch -u drm-tip/maintainer-tools
>
> - My plan is that we push an immediate revert of this code to the
>   gitlab repo (and only there) so it doesn't stick around.

In fact, push a revert to the GitLab repo _before_ pushing this revert
to the old repo.

> - fd.o admins recommended that we don't do a read-only copy of
>   maintaienr-tools at the old-place, since it's not a 1:1 match. For
>   everything else we're going to migrate there will be a read-only
>   copy with all urls working nicely, maintainer-tools is the only
>   exception here.

Right: pushing updates from gitlab -> git.fd.o would include pushing
the revert of this commit, which would stop auto-upgrading from
happening. Since we have a script which already rewrites remotes for
upgrades, might as well just have it properly EOLed in the old
location whilst moving from a branch to a separate repo.

Reviewed-by: Daniel Stone <daniels at collabora.com> # wearing both dim
hat and fd.o admin hat

Cheers,
Daniel