[vlc-devel] Migration to Merge Requests

[Thomas Guillem]

I want to say that I'm thrilled with the migration, gitlab is awesome.
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.

Best,
Thomas

On Mon, May 10, 2021, at 03:55, Pierre Ynard via vlc-devel wrote:
> > > 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."
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel