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

301–310 of 408 posts

Re: Wikimedia is moving to Gitlab

#301

Post by [deleted] »

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…

[deleted]

Re: Wikimedia is moving to Gitlab

#302

Post by mixologic »

"This raises the question: if Gerrit has identifiable problems, why can't we solve those problems in Gerrit? Gerrit is open source (Apache licensed) software; modifications are a simple matter of programming."

... And nuclear power is a simple matter of splitting atoms.

Re: Wikimedia is moving to Gitlab

#303

Post by AaronFriel »

u801e wrote: post #300
AaronFriel wrote: post #298

Earlier quoted context omitted.

To be polite, I think the target audience of these tools might not include you. While that workflow works for you and, apparently, scales for some very large projects like the Linux kernel, it isn't a good solution for an enormous number of people which is why tools like Github, Gerrit, GitLab, and others exist.

> To be polite, I think the target audience of tools might not include you. Insinuating that I'm a special case doesn't add to the discussion.

You aren't a special case, but if you don't see any flaws with your method of code review then I don't think you're the target market for code review tools.

Re: Wikimedia is moving to Gitlab

#305

Post by mpol »

GLJHunt wrote: post #284
mpol wrote: post #275

Earlier quoted context omitted.

(I already replied on a different thread but this might make more sense) A service like Stop Forum Spam might be a solution to this. It checks for IP address and email address and gives it a value based on how likely it is assumed to be a spammer. When they have to set up a new email account and maybe even a new IP address for every few accounts, it gets to be a lot of work soon. https://www.stopforumspam.com/ It has…

Appreciate the response - I'll look into now

Okay, thank you. I see Gitlab is mostly Ruby. Just to get a general idea of the code this is a simple PHP function to use it:

https://plugins.trac.wordpress.org/browser/gwolle-gb/trunk/f...

That function can be called when the register form has been submitted. It will return true or false. Forget about the transient stuff, that is just WordPres caching stuff.

You don't need an API key like with Akismet. You would only need it if you want to add or remove entries from the SFS database. It really is much simpler. Ofcourse you might want to have a checkbox in the settings. But still, in an afternoon you might be able to finish this :)

Wish you the best.

Re: Wikimedia is moving to Gitlab

#306

Post by nico_h »

GLJHunt wrote: post #234
ran3824692 wrote: post #109

Earlier quoted context omitted.

There's been a gitlab bug for almost 3 years to stop relying on recaptcha, https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45684 Debian, KDE and Gnome have never wanted to make their users run Google's nonfree javascript blob to contribute on their gitlab instance. There's been interest, Gitlab has done very little about it. Edit: other bugs about this can be found here https://gitlab.com/gitlab-org/gitlab-foss/-/…

We have a team currently working on improving the detection and mitigation of spam. We continue to look for ways to improve the security and user experience of our product. Our product includes the Akismet Spam filter which you can read more about in our handbook: https://about.gitlab.com/handbook/support/workflows/managing... . Further, Gitlab.com includes the ability to report abuse directly to our trust & safety t…

As mentioned above in the thread, multiple times, maybe a simpler solution to reduce spam is to remove incentives by:

- removing links (making them as plain text forcing users to copy paste them..) - hiding links from non-registered users (plain text to non-registered users, clickable for registered users), - blocking links from search engine crawlers (robots.txt / rel=nofollow...).

Maybe these fall in the "for each complex problem there is simple but wrong solution" but it sounds like it's worth a try.

Re: Wikimedia is moving to Gitlab

#307

Post by dionian »

badrequest wrote: post #34
q3k wrote: post #14

Earlier quoted context omitted.

I really don't mind the Gerrit UX - it seems to be optimized for daily use by programmers, not for onboarding speed. That's a tradeoff I'm very much okay with.

You're okay with the tool being difficult to use because you already know how to use it.

I already know how to use it and I hate how proprietary it is, I have so many other problems on my plate than customizing my Git to work a certain way. I like using the off the shelf tools that work nicely with the normal git workflows using temporary branches for MRs. And a nice UI that anyone can use with minimal effort or training.

Re: Wikimedia is moving to Gitlab

#308

Post by dionian »

llimllib wrote: post #172
q3k wrote: post #38

Earlier quoted context omitted.

I'm okay with it being slightly more difficult to get started with, in return for higher productivity in the long run, yes. Right now, after spending a similar amount of time both with GitHub PRs (and Gitlab MRs) and Gerrit, I still find Gerrit much easier and faster to use.

I'm generally okay with that tradeoff too, but we tried it early on at our company and the juice was not worth the squeeze, at least in our case. Designers and even many developers found it essentially impossible to use and the developers who were reasonably comfortable with it spent way too much time assisting others in attempting to use it. (fwiw I found myself somewhere in the middle - I like the model and underst…

Same. Cool idea in concept. Not something I have enough time to be interested in using heavily.

Re: Wikimedia is moving to Gitlab

#309

Post by marcinzm »

noizejoy wrote: post #241
cortesoft wrote: post #107

Earlier quoted context omitted.

I think the idea is that if you can't view issues without logging in, then google won't index your issues (because it can't view them), so you won't get people spamming in order to get into google

Over the years I've frequently seen Google search results showing things that require login to the indexed site. Has that changed?

I believe that requires the site giving google’s bot a logged in view rather than something google does themselves.

Re: Wikimedia is moving to Gitlab

#310

Post by u801e »

AaronFriel wrote: post #303
u801e wrote: post #300

Earlier quoted context omitted.

> To be polite, I think the target audience of tools might not include you. Insinuating that I'm a special case doesn't add to the discussion.

You aren't a special case, but if you don't see any flaws with your method of code review then I don't think you're the target market for code review tools.

Now you're claiming that I'm making an argument that I never made.

To be clear, the original statement was whether there was a better review tool compared to Gerrit for those who review code and use that tool for that purpose. I responded by suggesting the patch review via mailing list method and asked a follow up question about how Gerrit handled related commits and explained how that case was handled by the mailing list method.

Then you, not the person I originally responded to, decided to interject and, while claiming not to be rude, claims I'm saying something entirely different than what I actually stated.

Personally, I found that very off putting and extremely rude on your part.

Post reply on HN