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

361–370 of 408 posts

Re: Wikimedia is moving to Gitlab

#361

Post by grey-area »

edflsafoiewq wrote: post #254
grey-area wrote: post #224

Earlier quoted context omitted.

This is a typical spam profile. Usually they contain links, which search engines follow. https://forum.cloudron.io/user/cardioaseg

The link contains rel=nofollow.

That doesn't matter, see other comments below on Google's changing treatment of this attribute.

Also you'll find spambots posting on any open form on the internet even if it doesn't do them any good, because much of it is automated, so even if you hide the results the spam will still come in.

Re: Wikimedia is moving to Gitlab

#362

Post by alessioalex »

okhan wrote: post #212
q3k wrote: post #2

This is sad. In my experience, Gerrit is a much better code review system than Gitlab merge requests. But it is different from what people are used to.

I had to use Gerrit in a previous job, and _hated_ it. The UX is abysmal. Some folks loved it though, especially engineers working mostly on the backend. People with more of a frontend focus couldn't get past the awful user experience.

Can confirm, it's extremely off-putting to say the least. Having previously used Github, Gitlab, Bitbucket I find Gerrit very unusual. I have to Google on how to do basic stuff.

Re: Wikimedia is moving to Gitlab

#363

Post by lima »

JoshTriplett wrote: post #351
bawolff wrote: post #324

Earlier quoted context omitted.

> Gerrit is the one where each "pull request" has to be a single commit, right? Yes, but you can have changesets depend on each other, so its not that big a deal. (But you ca end up in rebase hell if you do that). You also get a version history of all the different versions of your commit. Ancedotally, during my use of gerrit, i never really wished to have multiple commits on a single changeset. > I'd prefer to merge…

> Ancedotally, during my use of gerrit, i never really wished to have multiple commits on a single changeset. People's tools shape their workflows; projects that use Gerrit tend to do more squashing of commits, because there's much more per-commit overhead. When I encountered Gerrit, I found it really frustrating to work with for this exact reason. Other aspects of it were great, but if you're used to "one logical ch…

The whole point of Gerrit is to keep doing "one logical change per commit", but reviewing them individually. Anecdotally, this results in much higher-quality reviews.

You can still group them by "feature" and merge them atomically by using topics.

Re: Wikimedia is moving to Gitlab

#364

Post by lima »

bawolff wrote: post #322
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…

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…

> 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 that is just cultural forces at wikimedia)

Can strongly recommend to remove "-1 code review" and require all comments to be resolved instead. Accomplishes the same goal why being more positive.

Re: Wikimedia is moving to Gitlab

#365

Post by dnsmichi »

csdreamer7 wrote: post #281
coder543 wrote: post #245

Earlier quoted context omitted.

Maybe GitLab needs an option to disable external linking, and filter any comment that contains an external link automatically

Or a nofollow option (add rel=nofollow)

That's a great idea. We have discussed ways of getting a trust level, and enable this for specific groups. Discourse uses the same system for preventing spam. "Good" bots detect the rel=nofollow and do not come back.

See my proposal here: https://gitlab.com/gitlab-org/gitlab/-/issues/14156#note_258...

Re: Wikimedia is moving to Gitlab

#366

Post by kevincox »

20after4 wrote: post #150
languagehacker wrote: post #40

In the past, I've found Gerrit to be reasonably good. Phabricator, on the other hand, not so much. Having worked with MediaWiki in the past on CRs, I think this will be a good move to modernize things for them. When faced with a similar task around the same time at Wikia (now Fandom), we chose GitHub while we were moving off of SVN. I'm glad we did at the time, even without all the additional features GitHub has. I u…

What issues did you have with Phabricator? I'm maintaining phabricator for the WMF and I'm interested in anything that could improve the user experience.

I was reviewing code in mercurial's phabrictor and it was awful the most notable was that when a new version was uploaded the comments stayed on the same line number instead of sticking to the same code.

There were other annoyances but it would move at least to "ok", maybe even "good" if that was fixed.

Re: Wikimedia is moving to Gitlab

#367

Post by kevincox »

dietrichepp wrote: post #9
q3k wrote: post #2

This is sad. In my experience, Gerrit is a much better code review system than Gitlab merge requests. But it is different from what people are used to.

Probably because you got used to Critique at Google ;) I agree though. I think the most important thing in a code review system is inline comments in the diff itself, and that’s something you get from Gerrit, Phabricator (Differential), etc. It encourages people to discuss the particulars of of a diff. Merge approval can be made contingent on resolving minor issues within a diff. Diffs are also approved on a per-diff…

I think the pull request model still makes sense. Of course if you stick to small changes it tends towards the patch model. However thete still some cases where two or three commits at once make sense. Even rarer there are cases where marging a bunch of changes into a "staging" branch before merging to master makes sense. I think this added flexibility is valuable, of course keeping the "patch style" single-commjt review great should probably be the priority.

Re: Wikimedia is moving to Gitlab

#368

Post by kevincox »

q3k wrote: post #23
dionian wrote: post #18

Earlier quoted context omitted.

> Clear mapping of change request == commit, was forced to use Gerrit by a client. I could never get the hang of this, I like to do frequent commits on short lived branches and using vanilla git. I never wanted any more features other than a nice UI to encourage people to review.

The nice UI for review works well exactly because it limits the functionality available to users and enforces a particular commit model. If you don't do that, you get the code review mess that are Github/GitLab PRs/MRs - difficult to tell apart how commits relate to the change and how it progresses through review, because the entire branch history is free-form.

It's possible to allow users to have multiple commits but still show review between the submitted "tip" commits. If you want you don't even need to show the other commits in the UI.

Re: Wikimedia is moving to Gitlab

#369

Post by kevincox »

js2 wrote: post #119
nemetroid wrote: post #64

Earlier quoted context omitted.

> With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. That's not quite true. Gitlab lets you compare any two "versions" of the force pushed branch.

Thanks. I haven’t used gitlab. I assumed it worked the same as GitHub. That’s good to know.

Yup, GitLab works as expected here. It's always surprised me how quickly the old commit is garbage-collrcted when you force-push a branch on GitHub. It causes weird errors in CI runs and breaks viewing the old commits.

Seriously I'll pay for those couple of KiB of space, just keep it around. (at least until the PR is closed)

Re: Wikimedia is moving to Gitlab

#370

Post by njitram »

leonidasv wrote: post #341
protoduction wrote: post #165

Earlier quoted context omitted.

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/c…

There are free and paid list of all ip addresses from datacenters like https://udger.com/resources/datacenter-list, they probably existing for specifically preventing this, so maybe thats an option here.
Post reply on HN