[vlc-devel] Migration to Merge Requests
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