[vlc-devel] Migration to Merge Requests

[Pierre Ynard]

> What is the gitweb feature you're talking about here?

Accessible HTML. Try browsing code.videolan.org in lynx for example,
and compare to git.videolan.org. Actually, after my experience with
the bug tracker I was surprised how much GitLab did still work for the
commit history part, but there are still issues with paging, and diffs
are unreadable due to their reliance on dynamic CSS formatting. It's
not a big deal in itself, but to be explicit, since you're asking, it
compromises:

- non-browser web tools;
- users with JavaScript disabled, or browser mods to disable some
  JavaScript in particular due to ads, cookies, and everything else that
  ruins modern web pages and their performance;
- but really, and more importantly for anyone, performance, as GitLab
  pages get slow and heavy on CPU and memory - GitWeb's static and
  uncluttered HTML pages feel so much more comfortable in contrast;
- users with challenged internet connectivity, or behind bad web proxies
  or tunnels, since browsing relies on AJAX;
- old unsupported browser versions where this newer JavaScript fails to
  run;
- probably blind users relying on accessibility tools such as
  text-to-speech or braille renderers.

I care about that, both in general and for personal reasons. Now GitLab
isn't realistically going to fix itself to take care of that, over
having a smooth and dynamic modern web UX with tags and emoji votes.
So either we choose aspects and sacrifice others, or we concurrently
maintain alternatives. I hope what I meant is clearer to you now.

>From a sysadmin point of view in particular, I suppose that one
single platform that does everything is probably easier to maintain
than hosting several tools, one for each task; let alone redundant
alternative ones.

> The push access to git.v.o/vlc.git is already disabled. I'm
> specifically not pulling from code.v.o, exactly because I wanted
> people to notice (without breaking their pipelines or processes) that
> the repo is not updated anymore so they can have a chance of migrating
> over to a new one.

Ah, yes, that makes sense indeed, if we want git.videolan.org to
eventually go. Otherwise, contributors sure will notice that push access
is disabled, and if git.videolan.org stays as a mirror then it makes no
difference if people keep pulling from it.

> At some point in the future I would really like to remove vlc.git from
> git.v.o just like we did for the majority of our projects in the years
> before.

Yes, I figure, and it makes sense. My main problem with that is all the
existing links to particular commits on GitWeb, in particular everywhere
in the bug tracker. A solution could be elaborate rewrite rules to
redirect those to the corresponding GitLab URLs, similarly to the plan
for Trac; the URL patterns are a bit more complicated though.

> It is annoying yes. Not possible to change this behaviour in Gitlab
> email notifications, but I think there are two other ways to tackle
> this issue:

Okay, sounds like good starting points to look at.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."