On Fri, Aug 24, 2018 at 8:52 AM, Jani Nikula jani.nikula@linux.intel.com wrote:
On Wed, 22 Aug 2018, Rodrigo Vivi rodrigo.vivi@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