[igt-dev] RFC: Migration to Gitlab

Daniel Vetter daniel.vetter at ffwll.ch
Fri Aug 24 12:03:30 UTC 2018


On Fri, Aug 24, 2018 at 8:52 AM, Jani Nikula
<jani.nikula at linux.intel.com> wrote:
> On Wed, 22 Aug 2018, Rodrigo Vivi <rodrigo.vivi at intel.com> wrote:
>> On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote:
>>> On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote:
>>>
>>> > - 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.
>>>
>>> Can you elaborate a bit on the issues here? The actual move-the-bugs
>>> process has been pretty painless for the parts of xorg we've done so
>>> far.
>>
>> I guess there is nothing against moving the bugs there. The concern is only on
>> doing everything at once.
>
> No, it's not just that.
>
> We have some automation using the bugzilla APIs directly, and
> someone(tm) needs to figure out how this should work with gitlab. Maybe
> we have a better chance of doing things with gitlab's APIs, maybe we can
> reduce our dependence on external logic altogether.
>
> We have special "i915 platform" and "i915 features" fields in
> bugzilla. We use a mailing list default assignee. Some of us use the
> "whiteboard" and "keywords" fields. Etc.
>
> I don't think figuring all this out is rocket science, but someone needs
> to actually do it, and get our workflows straightened out *before* we
> flip the switch. I'm just trying to figure out if that is a blocker to
> migrating the repos.

I think the mesa approach of flat-out disabling gitlab issues and
merge request is solid. That way there's no confusions with
contributions and bug reports stranded in the wrong place. This should
allow us to handle all the different feature sets gitlab provides
independently and as we see fit: Repo hosting, documentation/artifact
hosting, CI integration, patch submissions, issue tracking. We can
choose&pick what we think is good, and ignore everything else.

And of course if 1-2 years down the road things change, we can
reevaluate. I think for a rough timeline if things go well we'll have
igt and maintainer-tools migrated by end of year (just the repos,
nothing else), and a solid plan for migrating all the drm* repos next
year. Everything else is too far away to have solid plans for, or even
just a timeline.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the amd-gfx mailing list