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

341–350 of 408 posts

Re: Wikimedia is moving to Gitlab

#341

Post by leonidasv »

protoduction wrote: post #165
birdsbirdsbirds wrote: post #157

Earlier quoted context omitted.

Hopefully you are successful, but how can you scale? If it takes 5 seconds on a desktop, then a server can solve 500.000 captchas per month. At $5 per month, a spammer can still send 1.000 messages for a cent.

It's not enabled yet in production - but the main mechanism is by increasing the difficulty as more requests are made from an IP in a certain timeframe (it's basically rate limiting at that point). Think: every 3rd request in a minute doubles the difficulty with some cooldown period. With that the cost (and complexity) of an attack can hopefully be in the same ballpark (or higher) than ReCaptcha - without your end us…

I love this concept of proof-of-work captchas, but there's a growing number of tools and ways to bypass IP blocks via IP rotation[1], specially after the explosion of IaaS providers. How do you intend to tackle this?

[1] Some examples: https://rhinosecuritylabs.com/aws/bypassing-ip-based-blockin... https://oxylabs.io/products/real-time-crawler https://github.com/alex-miller-0/Tor_Crawler https://www.scrapinghub.com/crawlera/

Re: Wikimedia is moving to Gitlab

#342

Post by hombre_fatal »

dannyw wrote: post #196
boneitis wrote: post #192

Earlier quoted context omitted.

Many bots are likely still powered under the hood by humans. On my backlog of projects to do is to make a browser extension that solves the more obnoxious captchas for me, as I'm regularly behind vpn and fall into ridiculously long solve loops. On the most popular api i could find, $10 buys you a shockingly LOT of solves (not that I've tested it yet). It is automatable but ultimately still powered by humans.

It’s incredibly sad how the open web is being destroyed by google’s recaptcha.

You're barking up the wrong tree. Bad actors create abuse and spam which they can do because of fundamental weaknesses in the design of the internet. People trying to solve that reality with Recaptcha (and Cloudflare for that matter) aren't the ones destroying the internet.

Re: Wikimedia is moving to Gitlab

#343

Post by bawolff »

zzzeek wrote: post #340
bawolff wrote: post #322

Earlier quoted context omitted.

Wikimedia was already using mirroring to github (however we didn't accept pull requests). I'm pretty sure most of the anti-gerrit sentiment at wikimedia was about gerrit as a code review tool. My personal experience with it (as a mediawiki developer) is gerrit has a lot of UI bugs (although it has gotten better). I also suspect it encourages a code review culture that is overly nitpicky and risk averse (but perhaps t…

I'm not familiar with any UI bugs of any kind, but we don't use the "live editing" feature, maybe that's where you had problems. The big issue with Gerrit is on the "getting plugins to work" side of things, as they are kind of ad-hoc and almost totally undocumented, as well as the access model is too complicated but once that's all working, there is no need to deal with it. nitpicky culture, we maybe have that proble…

Wikimedia was using a super old version of gerrit for a long time. They upgraded recently (although the upgrade happened at roughly the same time as i left my job and took a step back from wikimedia so i dont have much experience with the new version).

I think Wikimedia struggles a lot with code review culture in general. Different people have conflicting ideas about what good code looks like. It used to be very nitpicky (i've had code rejected in the past for using (php's) intval() instead of casting to int. I've also had code rejected for casting to int instead intval().) But that's improved quite a bit with better precommit lint tools. The length of the feedback cycle is very long and sometimes feels like its mostly about who you know (e.g. the last patch i submitted i did on sept 9 for a decently serious bug. First actionable feedback (which was relatively minor things of the form use a constant named ONE_MINUTE instead of 60) was on oct 15. Thats kind of a long time to wait for code review imo). Anyways, its just not fun to contribute when code review is so unpredictable and long.

Hmm. Guess i got off on a bit of a tagent there. I do think gerrit has some usability issues, but i think that's hardly the main problem.

Re: Wikimedia is moving to Gitlab

#344

Post by lacksconfidence »

kortilla wrote: post #299
lacksconfidence wrote: post #295

Earlier quoted context omitted.

It's not a force push under the hood. Under the hood a new branch is created (first patch set is /refs/changes/nnnn/0, second is /refs/changes/nnnn/1, etc.). From the end user perspective the result is quite plausibly similar to force push.

The branch model must have changed. I used to push directly to a branch that was the change number (not the revision number) and of course had to force because it was the same. So what happens when you push to changes/nnnn/12 when revision 11 hasn’t been created?

At least the way our installation works we don't push to changes/nnnn/12, rather changes are pushed to refs/for/{branch} (often refs/for/master). This endpoint isn't an actual branch. It triggers gerrit to look up the nnnn for the Change-Id in the commit message and create the appropriate branch for the next patch set.

Re: Wikimedia is moving to Gitlab

#345

Post by epage »

WrtCdEvrydy wrote: post #181
Cthulhu_ wrote: post #57

Earlier quoted context omitted.

After reviewing some tools we went with Phabricator ourselves; it's not ideal, but it's open source (read: free, we can't afford a $x / seat license) and self-hosted.

Phabricator is amazing as an all-in-one solution for a small shop.

I'm curious about this because I've wanted to get off Phab as soon as I started using it

- Whats your thoughts on "arc"? It seems like a whole can of worms of problems you can run into with basic branch flows. I know teams that have complex branch flows and it is a nightmare. Same for Windows users.

- What do you use for a CI? How well does the integration work for you?

- How is it with tracking conversations on Diffs?

- Any particular plugins or bots for it that help make the difference?

Re: Wikimedia is moving to Gitlab

#346

Post by boneitis »

hombre_fatal wrote: post #342
dannyw wrote: post #196

Earlier quoted context omitted.

It’s incredibly sad how the open web is being destroyed by google’s recaptcha.

You're barking up the wrong tree. Bad actors create abuse and spam which they can do because of fundamental weaknesses in the design of the internet. People trying to solve that reality with Recaptcha (and Cloudflare for that matter) aren't the ones destroying the internet.

I don't think it's so much the wrong tree as it is but one tree in a forest to be barking up.

All the maturely developed bot filters frequently throw me in an endless battery of tests that have me giving up in frustration before finally making it through to content I'm requesting.

> aren't the ones destroying the internet

IMO they are every bit as much destroying it as the abusers they're claiming to fend off.

Re: Wikimedia is moving to Gitlab

#347

Post by brlewis »

leipert wrote: post #276
edflsafoiewq wrote: post #254

Earlier quoted context omitted.

The link contains rel=nofollow.

I don’t know for sure, but I think our Markdown implementation adds nofollow.

I used to think that spammers would stop if their spamming didn't win them any results. But they don't care. They spread their spam as widely as possible without trying to prune out the places where it does them no good.

Re: Wikimedia is moving to Gitlab

#348

Post by fireattack »

h0l0cube wrote: post #314
AaronFriel wrote: post #303

Earlier quoted context omitted.

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.

I have no dog in this fight, but you stated: > it isn't a good solution for an enormous number of people .. without providing any insight or justification for that belief. So an interesting and productive tangent might be to elucidate what you believe those flaws are? Unpacking this question might even lead to some good UX ideas that can be applied to today's review systems?

I would provide one from someone who is not a dev or SE.

I honestly never fully understand how to read the maillist patch. The plain text format makes it very hard to understand what's going on. I'm sure I will understand it better or even prefer it if I use it long enough, but then again I can instantly understand code reviews on GitHub/GitLab/Gerrit.

Re: Wikimedia is moving to Gitlab

#349

Post by h0l0cube »

fireattack wrote: post #348
h0l0cube wrote: post #314

Earlier quoted context omitted.

I have no dog in this fight, but you stated: > it isn't a good solution for an enormous number of people .. without providing any insight or justification for that belief. So an interesting and productive tangent might be to elucidate what you believe those flaws are? Unpacking this question might even lead to some good UX ideas that can be applied to today's review systems?

I would provide one from someone who is not a dev or SE. I honestly never fully understand how to read the maillist patch. The plain text format makes it very hard to understand what's going on. I'm sure I will understand it better or even prefer it if I use it long enough, but then again I can instantly understand code reviews on GitHub/GitLab/Gerrit.

I've never had to use a maillist patch myself, but from the ones that I've glanced at, I have this same problem, that formatting, syntax highlighting is absent. It seems like this would be an easy problem to fix by using a better viewer, so that might be enough to make it comprehensible.
Post reply on HN