[vlc-devel] Migration to Merge Requests

Rémi Denis-Courmont remi at remlab.net
Mon May 10 14:54:47 UTC 2021

Le maanantaina 10. toukokuuta 2021, 11.23.14 EEST Thomas Guillem a écrit :
> I want to say that I'm thrilled with the migration, gitlab is awesome.

No, it's not. There are pros and cons and they are situational. If I had the 
same employer and JD as you do, I'd probably find it awesome for my own 
purposes well. But it is most defintely not universally awesome.

And besides the (dis)advantages of gitlab per se, we engendered had two other 
sets of really unnecessary problems: the mythology surrounding the switch to 
gitlab, and the frankly comparatively badly managed migration.

Now if you recall the discussion to switch to Gitlab way back in the Paris 
2018 general assembly, it was all about making contributions easy/easier, how 
Gitlab would enable "drive-by" contributors and remove "gateways" (exact 
quotes). But that was all myths. We lied to ourselves. Github would probably 
have achieved that, but a private Gitlab instance most definitely utterly 

I don't belong in the demographic of new or occasional contributor, so I don't 
really care, but there is a huge gap between built-up expectations and actual 
results. When all is said and done, it's actually much easier to contribute a 
small patch with the old work flow... Unsurprisingly, this has angered many bug 
reporters and small patch submitters in what is still a rather short period of 
time. And thus, it made room for a lot of relevant or irrelevant, but 
nevertheless true, criticism, and a feeling of betrayal by those (including 
myself) who are not inconditional fans of Gitlab,

Then Gitlab proper is not all rosy. The bug management is much *faster* than 
Trac's. But on the other hand the commit review has become much *slower*, is 
buggy and requires an abnormally wide browser window to be legible. It's also 
less flexible than email in tagging new/unread/important MRs.

Still the worse aspect of all has been the transition. On a technical level, 
Konstantin seems to have done a very fine job. But for comparison, in the 
previous two migrations, we had proper guidelines for developers and testers 
to change their (CLI) workflow, even though there was ample documentation on 
the Internet. This time, we've only had a URL and unhelfully been told to 
Google the documentation. Is Google even able to find documentation on the 
review bot? I doubt it...

Likewise, the bug migration was abotu as terrible. To me, it feels like the 
request for feedback was just a rhetorical question since none of the errors 
raised were addressed, e.g.:
- loss of the unreproducible tag on old bugs,
- corruption of existing stack traces.

Frankly, all my goodwill in this switch has been expanded, I'm pissed and my 
efficacy and motivation is rock bottom. It does not help that we are now over 2 
years and still counting with a confusing and broken new UI, and an unstable 
bloated media library. This is the 0.9.0 release cycle all over again, exactly 
as I'd warned upfront two years ago.

> It's way more easy for me to keep track of all the submissions.
> Small tip: I still use my mails a lot with gitlab. I set up mails
> notifications (the bell icon at the upper-right of
> https://code.videolan.org/videolan/vlc) to send me a mail when a new MR or
> issue is created.
> If you want to receive notifications when an issue/MR is updated (new
> commits, comments...), you can either assign it to yourself, or check the
> "Notifications" checkbox at the bottom-right.

I get way too *many* notifications on bugs and MRs that I am not competent for, 
not too few.

Реми Дёни-Курмон

More information about the vlc-devel mailing list