[vlc-devel] Migration to Merge Requests

[Pierre Ynard]

> > 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?
>
> Please do the script for that.

I'm not part of the sysadmin or GitLab migration circles, remember? Are
you suggesting that this is a matter of technical complications, and
that as an outsider without access I'm better placed to tackle them?
I did assume that this would be simple configuration, but maybe I was
wrong.

> > 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?
>
> It's already the case, if you follow the repo.

Great! So people who'd like to review merge requests by email can do it
this way already? Rémi, how does this sound to you?

> > 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?
>
> The bug is upstream on gitlab. Feel free to bump it.

I'm glad to hear it. Can you please share the URL, so we can all check
and follow its status, as I requested? Perhaps could you share the URL
if you'd like me to bump it?

> > 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.
>
> Edit a wiki page for that. Please document it.

First, no, YOU document YOUR migration. Second, if you want me to
take charge of this, okay, I'll fix it alright, by removing the 2FA
requirement. Don't ask me to document your designs and decisions, I'm
not in your head. The point is, as you could have guessed by my request
for documentation, that I have little expertise with 2FA. The method I'm
most familiar with is sending a code by SMS to your phone number; and I
don't think that's one even available here.

And if nobody in the migration project has better expertise and design
plans about 2FA, other than it sounds nice and we'd like to have it,
then perhaps it would be wiser to leave that feature disabled for now.

> > 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.
>
> Send the patches attached to your email to that address...

That was still unclear. If anyone else has the same question, this doc
explains it:

https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#new-merge-request-by-email

> > Also, I need to be logged in with an account + 2FA to access this
> > feature.
>
> It's always the same address.

That's beside my point. But anyway then, we could have a generic GitLab
account, and make its email access available through a moderated public
email address. This way, anyone even unregistered could send patches -
just like on vlc-devel@ - while still getting the technical benefits
from GitLab such as CI and tracking.

Or is there a reason why we'd want to force a code.videolan.org account
on any participant?

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

How about yes?

I'm sorry, is there a problem with my making suggestions? Perhaps you
could indulge me with more than unbothered one-liner non-arguments?
And even if you don't feel like talking about it with me, could you
please still do it out of accountability for your own project instead of
dismissing onto me the responsibility for fixing it?

> > 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.
>
> Click on members, and you will see that.

Thanks. Is this supposed to be a group of people to deal with
contingencies? So what about the policy aspects of these privileges?

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