Hi Dan,
On 22 August 2018 at 12:44, Daniel Vetter daniel.vetter@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