gitlab migration

[Daniel Stone]

On 9 June 2018 at 00:11, Eric Anholt <eric at anholt.net> wrote:
> Adam Jackson <ajax at redhat.com> writes:
>> I'd like us to start moving repos and bug tracking into gitlab.
>> Hopefully everyone's aware that gitlab exists and why fdo projects are
>> migrating to it. If not, the thread about Mesa's migration provides
>> some useful background:
>>
>> https://lists.x.org/archives/mesa-dev/2018-May/195634.html
>>
>> This should be mostly mechanical, except for moving some of the older
>> junk into the archive and deciding which drivers _not_ to move yet (I
>> imagine intel has some of its processes hooked up to bz, for example).

Migrating bugs is pretty easy, but there are currently over 2800 bugs
in the 'xorg' product, of which 921 are in the server +
xf86-video-modesetting + xf86-input-{evdev,libinput} components. The
import does preserve components as tags, and it does add a 'bugzilla'
tag to make it fairly easy to see what has and hasn't been triaged,
but I would seriously recommend doing a massive clean-up pass before
doing the migration. Easier said than done, of course.

>> As far as contribution model, I'd personally prefer to stop using
>> mailing lists, and for most of the X components I expect that's
>> probably an improvement, because most components do not have especially
>> active maintenance and it's currently very easy for patches to get lost
>> in the mailing list history. Conversely for the server it can be
>> difficult to keep track of a patch series' approval state. Again, not
>> solely my decision to make, so I'd like to hear some rough consensus on
>> how to proceed. Anyone with strong opinions, please do speak up.
>
> I, for one, would love to see xserver use a MR-based contribution
> process.  Every once in a while I go to review some old patches I had
> personally marked as still to be reviewed, and find they're already
> merged.  I'm sure the reverse is happening, too.
>
> For our libraries with less active maintainership, MRs that stay open
> until they're actually handled should be an even bigger win.
>
> I'm also *really* interested in a merge process that runs through the
> server's automated tests before the code hits master.  I know that won't
> be day 1, but gitlab is progress toward that.

Totally AOL from me. It looks like the repo currently runs exactly the
same tests on GitLab CI as it did through Travis, for Linux at least.
For Windows we can set up a GitLab -> Appveyor hook to check and just
reuse that directly. That leaves us with OS X: we don't have an OS X
CI worker set up for fd.o, and Travis have flatly said they don't plan
to build any integration with GitLab. GStreamer do have OS X workers
for Jenkins, and they're actively looking into migrating to GitLab; I
believe their OS X worker more or less works. Maybe once they've moved
we could reuse that and cover all three platforms that way.

I'd be interested to see the relative speed of our worker compared to
Travis. If it is a bit slower, then we're actively working on sourcing
more CI workers, both x86 and ARM; hopefully within the month or so.
If it's already faster, great.

Cheers,
Daniel