[vlc-devel] Migration to Merge Requests

[Pierre Ynard]

There's been some discussion about the usability of GitLab. I thought
I'd try to move things forward again in a constructive way.

It's been pointed out that GitLab has some accessibility issues, among
others:

- the web UI requires JavaScript, even for read-only browsing
- perhaps because of its heavy and unwarranted reliance on JavaScript
  rendering, the web UI has performance issues
- it requires an account + two-factor authentication to participate
  in any way (creating an account as technical prerequisite is a
  paradigm from the previous century, unless we're talking about
  popularity-oriented platforms such as social media)
- it's not friendly towards offline workflows
- in fact the platform workflow it mandates could be a bit heavy and
  inflexible, and we should question what the number of open merge
  requests can be a symptom of and whether it causes undue burden

> > What's the synchronization status between code.videolan.org and
> > git.videolan.org, for either vlc or vlc-3.0?
>
> Currently, nothing is synchronized.

git.videolan.org's GitWeb can offer an alternative to some of GitLab's
shortcomings. Well how about we disable push access and make it
automatically pull from code.videolan.org?

The new push notifications sent to the vlc-commits mailing list don't
show individual commits within a merge request. Would it be possible to
fix this?

When a new merge request is open, would it be possible to also send
email notifications about it? It's already a common convenience feature
that when you receive a bug tracker ticket update notification by
email, you can simply reply to that email to comment; it doesn't seem
far-fetched to have this for merge request reviews too?

Can we get an update on the effort to alleviate the two-factor
authentication requirement? Also, if I remember correctly, when getting
on board with code.videolan.org, the redirection to the 2FA page really
blocks you from doing anything while logged in until you deal with it.
That's not great UX. Perhaps we can alleviate this too?

Could we have this 2FA page document or link to a wiki page or something
giving instructions and recommended options, in particular for people
without smartphones or 2FA devices? E.g. oathtool and how to set it
up? I didn't mind asking questions on this mailing list last time, but
really this should have been documented to me better.

> > I surmise that this implements and takes the place of the mandatory
> > code review process. Is it still cool to post, review and process
> > patches through the mailing list?
>
> Send a MR by email.
> See the email at the bottom of the MR page.

Instructions unclear: it gives me an email address to send to without
explaining what the contents should be. I only know how to send commit
patches by email, one per email; I don't know how to send merge request
emails.

Also, I need to be logged in with an account + 2FA to access this
feature. And the warning notice about it being a super secret address
with which others could hijack my account is laughable here: as I said,
the account creation prerequisite for everything is a last-century
paradigm, especially striking for code contributions that should be
considered on their contents' merits, and regardless of authorship or
submitter identity tracking. Git was designed around lifting the burden
of that centralized account model, so nice regressive undermining that
there.

How about my patch gets processed on the mailing list instead?

> Unless you are maintainer (meaning TC+roots), you cannot push
> directly.

And who's this? What's roots, sysadmins? Are there policy reasons
around this? Can it be openly documented, or is it like for now, an
unspecified circle and unspecified technical circumstances to be
allowed to bypass the mandatory GitLab MR workflow? This is meant as a
suggestion for improvement, but it threads with the heaviness of the
mandatory workflow.

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