On Wed, Aug 22, 2018 at 3:13 PM, Jani Nikula <jani.nikula at linux.intel.com> wrote: > On Wed, 22 Aug 2018, 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). >> >> 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. >> >> - 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. >> >> - 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. >> >> 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. > > Just a couple of concerns from drm/i915 perspective for starters: > > - Patchwork integration. I think we'll want to keep patchwork for at > least intel-gfx etc. for the time being. IIUC the one thing we need is > some server side hook to update patchwork on git push. > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > drm-intel for the time being. Doing that migration in the same go is a > bit much I think. Reassignment across bugzilla and gitlab will be an > issue. Good points, forgot about both. Patchwork reading the mailing list should keep working as-is, but the update hook needs looking into. Disabling gitlab issues is a non-brainer, same with merge requests. Mesa is already doing that. For bugs I think it's best to entirely leave them out for now, and maybe reconsider when/if mesa has moved. Before that I don't think gitlab issues make any sense at all. For merge requests I think best approach is to enable them very selectively at first for testing out, and then making a per-subproject decision whether they make sense. E.g. I think for maintainer-tools integrating make check and the doc building into gitlab CI would be sweet, and worth looking into gitlab merge requests just to automate that. Again best left out of scope for the initial migration. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
