Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wikimedia is moving to Gitlab

mediawiki.org

Post reply on HN
Print view View original

401–408 of 408 posts

Re: Wikimedia is moving to Gitlab

#401

Post by eru »

u801e wrote: post #356
fireattack wrote: post #355

Earlier quoted context omitted.

I will be honest, I don't even use email client :/

True, I suppose most people use Gmail or one of the other major email providers through a webmail interface. I haven't been able to get Gmail or Hotmail to display threaded messages the way they're displayed in Thunderbird and they tend to display messages using a variable width font. In that context, reviewing code would be difficult, if not impossible, to do via email.

That should be an easy problem to fix:

Just send out email in HTML format with the code portions set to fixed width font and syntax highlighting already applied. Should display just fine in GMail.

Re: Wikimedia is moving to Gitlab

#402

Post by edchan »

ran3824692 wrote: post #176
sytse wrote: post #163

Earlier quoted context omitted.

I think the focus of our Trust and Safety team has been on GitLab.com and not on all GitLab instances. We'll discuss changing this.

Thank you.

GitLab team member here. We just added a new page to our Handbook where we share approaches to preventing, detecting and mitigating spam on self-managed instances of GitLab. https://about.gitlab.com/handbook/engineering/security/opera...

We want to hear from you! Instructions on how to contact us: https://about.gitlab.com/handbook/engineering/security/opera...

Re: Wikimedia is moving to Gitlab

#403

Post by basicexploit »

u801e wrote: post #382
izietto wrote: post #381

Earlier quoted context omitted.

Which plugin are you using? it seems life-changing to me

This is the one I'm using: https://github.com/Qeole/colorediffs . I installed it several years ago, so I'm not entirely sure whether you can install it on a current version of Thunderbird, but it is still working with my installation.

I might try it out as well! Thanks for it.

Re: Wikimedia is moving to Gitlab

#404

Post by wdb »

boleary-gl wrote: post #188
wdb wrote: post #182

Earlier quoted context omitted.

Personally, I also think, GitHub's Checks API, and it Github bots. Gives a much better experience compared to GitLab. On a daily basis I am confused about how diff's are being rendered in GitLab merge requests, as it has a weird way to render ${blah} in strings in lines. Also when you want to check if an issue exists in GitLab own repository, you always end up in some jungle of redirected tickets. Just now I got redi…

Can you share an example or screenshot of what you mean around the rendering issue in merge requests? As for the issue redirects - it does stink. It's an artifact of our move to a single code base for CE and EE [1]. A lot of issues have long-standing SEO so the "old" issue often comes up in a Google search. [1] https://about.gitlab.com/blog/2019/08/23/a-single-codebase-f...

Yes, for example, in today's pull request, I added a new file and now in my Typescript file it renders things like this, which I find confusing: https://imgur.com/a/C82hcMK

Re: Wikimedia is moving to Gitlab

#405

Post by u801e »

eru wrote: post #401
u801e wrote: post #356

Earlier quoted context omitted.

True, I suppose most people use Gmail or one of the other major email providers through a webmail interface. I haven't been able to get Gmail or Hotmail to display threaded messages the way they're displayed in Thunderbird and they tend to display messages using a variable width font. In that context, reviewing code would be difficult, if not impossible, to do via email.

That should be an easy problem to fix: Just send out email in HTML format with the code portions set to fixed width font and syntax highlighting already applied. Should display just fine in GMail.

> Just send out email in HTML format with the code portions set to fixed width font and syntax highlighting already applied

That won't work because people actually download those email messages and apply them to their local repository with the git am command and they also expect to be able to reply to the email inline when commenting on a patch. Also, for mail clients that don't support HTML rendering, it would be much more difficult to read or respond to an HTML email.

Re: Wikimedia is moving to Gitlab

#406

Post by laughinghan »

protoduction wrote: post #258
laughinghan wrote: post #232

Earlier quoted context omitted.

There doesn't appear to be any discussion on your website or on GitHub about why, to be blunt, this is even a good idea in the first place. A classic 2004 paper, "Proof-of-Work" Proves Not to Work [0], explained that the fundamental problem with proof-of-work bot filters is that attackers will always be able to solve the cryptographic puzzle faster than legitimate users. A touch of security-through-obscurity can help…

I'll try to provide my thoughts on each of the issues you've mentioned, let me know if there's something I missed. On using blake2b: I chose blake2b as I was looking to use a hash function that is small in implementation, readily available and already optimized. With WebAssembly the solver can achieve (close to native) speeds and be least be an order of magnitude or two closer to optimized GPU algorithms. Using speci…

Thanks for your detailed response.

I've seen all the projects claiming to have broken ReCAPTCHA—often using Google's own ML services, hilariously—but it's unclear to me how broken image/audio CAPTCHAs are in practice (and the number of GitHub repos doesn't seem like a good measure to me). If they really are completely broken, then why are they still so widely used? If they really are completely broken by ML, how do human CAPTCHA-solving services stay in business?

FriendlyCaptcha optimizes for the end user (privacy + effort + accessibility)

Good point. I am concerned though that burning CPU cycles on the proof-of-work uses battery life if the end-user is on mobile, without getting their getting any choice in the matter. What if, given an informed choice, they would have preferred an image CAPTCHA? (On the other hand, that could use more cellular data. Might be good to run the numbers on this too.)

even with a million users on one IP there won't be tens of users signing up to some forum per minute

I think this is a bad choice of threat model. "Some forum" would likely be better off with simpler measures, like a hidden honeypot textbox: https://dev.to/felipperegazio/how-to-create-a-simple-honeypo...

Re: Wikimedia is moving to Gitlab

#407

Post by eru »

u801e wrote: post #405
eru wrote: post #401

Earlier quoted context omitted.

That should be an easy problem to fix: Just send out email in HTML format with the code portions set to fixed width font and syntax highlighting already applied. Should display just fine in GMail.

> Just send out email in HTML format with the code portions set to fixed width font and syntax highlighting already applied That won't work because people actually download those email messages and apply them to their local repository with the git am command and they also expect to be able to reply to the email inline when commenting on a patch. Also, for mail clients that don't support HTML rendering, it would be mu…

I would assume you'd sent both a text message and an HTML message?

Re: Wikimedia is moving to Gitlab

#408

Post by pedroms »

augustohp wrote: post #242
zzzeek wrote: post #116

I think I have some relevant experience here. We host all of our projects on github: https://github.com/sqlalchemy/ yet we also use gerrit! https://gerrit.sqlalchemy.org/ users send us pull requests, and they never have to deal with Gerrit ever. We use a custom integration, the source code to which is here: https://github.com/sqlalchemyorg/publishthing/tree/master/pu... and then we mostly bidirectional synchronizatio…

I am yet to know people who Review code and use Gerrit to name a better solution. I belonged to a team that used Gerrit for Review and Hosting, we changed to hosted Gitlab because people missed a "GitHub-like UI" they were used to. It was unanimous that Code Review on Gerrit was way better: 1. You start reviewing the commit message, that is the first touch point with a change everyone has 2. Navigation is done from f…

I'm a Product Designer at GitLab and I appreciate your feedback.

We are well aware of the advantages that Gerrit has over GitLab and how these are emphasized when teams migrate to GitLab. We are working on improvements that will help mitigate this. Specifically, targeting your points:

1. We're discussing ability to comment on commit messages: https://gitlab.com/gitlab-org/gitlab/-/issues/19691 2. From version 13.2 you can opt to show one file at a time, in your user preferences: https://gitlab.com/gitlab-org/gitlab/-/issues/222790. We have also listed a number of improvements to this feature in https://gitlab.com/groups/gitlab-org/-/epics/516.

Could you expand on point 3.b? If the commented line hasn't changed from version A to B, you should be seeing the comment in version B. Or maybe you're referring to something else?

Post reply on HN