Hi. On Tue, 28 Aug 2018 at 20:31, Daniel Vetter <daniel.vet...@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 <dani...@collabora.com> # wearing both dim hat and fd.o admin hat Cheers, Daniel _______________________________________________ dim-tools mailing list dim-tools@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dim-tools
