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

281–290 of 408 posts

Re: Wikimedia is moving to Gitlab

#281

Post by csdreamer7 »

coder543 wrote: post #245
gramakri wrote: post #211

Earlier quoted context omitted.

I am not entirely sure. See https://forum.cloudron.io/users , if you go to say page 10 or something you will see all sorts of nonsense. I am still trying to figure what the best way to fight this spam (because captcha is enabled and required to even create accounts). But these are real people and not bots. I know this because they even post new messages all the time.

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)

Re: Wikimedia is moving to Gitlab

#282

Post by u801e »

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 am yet to know people who Review code and use Gerrit to name a better solution.

What about reviews via patches sent to a mailing list?

I haven't looked into Gerrit for a while, so one question I have is how it handles related commits? The mailing list approach can group them in a single thread tied by a cover letter message where each commit along with the associated diff from the parent working tree is a message which is a reply to the cover letter message.

Re: Wikimedia is moving to Gitlab

#283

Post by remram »

_ikke_ wrote: post #248
detaro wrote: post #89

Earlier quoted context omitted.

It doesn't stop the spam from being created, but it does stop the spam from ruining your site reputation in search results was the suggestion I guess.

But the goal is to prevent spam in the first place. I don't think these bots will verify robots.txt to see if the spamming is effective. They just spam anything they can get their hands on.

They probably don't have general code that spam any form, it's more likely that they have code specific to GitLab CE instances that knows to post snippets. If GitLab changes their default configuration so that those snippets are no longer indexed by Google, the spammer are likely to stop using that GitLab CE spamming script, after a while.

Re: Wikimedia is moving to Gitlab

#284

Post by GLJHunt »

mpol wrote: post #275
GLJHunt wrote: post #234

Earlier quoted context omitted.

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…

(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

Re: Wikimedia is moving to Gitlab

#285

Post by u801e »

huskyr wrote: post #10
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 guess you can get the hang of Gerrit, but i tried it out a couple of times (i occasionally do work on projects in the Wikimedia git repo) and is pretty evident that the interface is written by developers with little knowledge of user experience. Moving stuff to Gitlab will probably increase the number of volunteer contributions, at least i'm more interested in contributing more now.

> Moving stuff to Gitlab will probably increase the number of volunteer contributions, at least i'm more interested in contributing more now.

Is there a project out there that originally used something like Gerrit, Phabricator, Reviewboard, or a mailing list that moved to Gitlab or Github where the number of contributions increased after the change?

Re: Wikimedia is moving to Gitlab

#286

Post by shandor »

20after4 wrote: post #160
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.

Gerrit is so off-putting to new users that many never get over the learning curve. At Wikimedia we want to be welcoming to new contributors. We also have to consider the on-boarding experience of new staff members, as well as the productivity of staff and long-time contributors. Gerrit satisfies some people who have used it for a long time but it is almost universally disliked by newcomers. When your users are volunt…

Curious, did you think of moving also the repos and reviews to Phabricator, as I recall WMF using that for task management?

Re: Wikimedia is moving to Gitlab

#287

Post by aprdm »

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 wonder how gerrit compares to reviewboard (https://www.reviewboard.org/)

Re: Wikimedia is moving to Gitlab

#288

Post by SahAssar »

sayhar wrote: post #71
zeitg3ist wrote: post #47

Earlier quoted context omitted.

I don’t know about Wikimedia being super cautious when adopting technologies... I host a MediaWiki instance and there’s been a lot of “not so cautious” tech decisions in the past. Jumping early on the HHVM train (which they eventually had to leave); adopting Lua for wiki modules; developing Parsoid as a Node service (now rewritten in PHP)... None of these was the “safe option”; in some cases it worked out well but in…

What's wrong with HHVM? Honestly asking, I have no real context beyond knowing it is a FB invention

HHVM got very little community adoption and never had strong promises to stay compatible with the rest of the PHP ecosystem.

Re: Wikimedia is moving to Gitlab

#289

Post by trynewideas »

jancsika wrote: post #53

Anyone thinking of moving to their own Gitlab instance with Gitlab CE-- either stay on Github or prepare to waste your time dealing with user spam bots that pollute your site's search results. In other words-- if you want the common use case for a FOSS project: 1. publicly viewable main repository with publicly viewable issue tracker 2. requirement to log in to view all snippets, user profiles, perhaps even other rep…

I'll be curious to see whether they even use GitLab user auth. For Gerrit (and Phabricator), Wikimedia already requires contributors to have a dev account on Wikimedia's LDAP system: https://wikitech.wikimedia.org/wiki/Help:Create_a_Wikimedia_...

Re: Wikimedia is moving to Gitlab

#290

Post by delsarto »

huskyr wrote: post #10
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 guess you can get the hang of Gerrit, but i tried it out a couple of times (i occasionally do work on projects in the Wikimedia git repo) and is pretty evident that the interface is written by developers with little knowledge of user experience. Moving stuff to Gitlab will probably increase the number of volunteer contributions, at least i'm more interested in contributing more now.

The git-review [1] tool makes it trivial to interface with Gerrit (it's likely packaged for your distro, see [2]). I've found many people struggling with Gerrit don't know about it and it has made their life significantly easier. It handles all the magic of pushing to refs so that you never need to know about it. You drop a .gitreview in your project and then your work-flow is literally

    $ git checkout -b my-feature-branch
    $ emacs ... 
    $ git add -i ...
    $ git commit
    $ git review
     read reviews, edit
    $ git add -i ...
    $ git commit --amend
    $ git review # push new change revisions
You can download an upstream change to use locally with "git review -d 123456"

[1] https://docs.openstack.org/infra/git-review/ [2] https://www.mediawiki.org/wiki/Gerrit/git-review

Post reply on HN