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

121–130 of 408 posts

Re: Wikimedia is moving to Gitlab

#121

Post by jancsika »

jefftk wrote: post #70
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…

Can you say more about how it's a problem if people can view things without logging in? Naively I would have seen that as a plus.

Because spammers fill the publicly viewable things-- like snippets and user profiles-- with spam. If it can be viewed without logging in, then they get it indexed with Google and it dilutes the search results.

Nobody views snippets and user profiles as a common part of daily development, so it takes time away from development to investigate those things to prune them. And if you don't prune it fast enough, it gets into the search results at which point it's even more of a pain in the ass to remove (even using Google's webmaster tools).

Re: Wikimedia is moving to Gitlab

#122

Post by mxskelly »

driverdan wrote: post #96
mxskelly wrote: post #55

Earlier quoted context omitted.

Oh right yeah pressure from China, like what got youtube-dl entirely removed... Oh wait no that was the US government.

I downvoted you because it wasn't the government that filed the takedown. Perhaps you mean "a private company using laws enacted by the US government?"

What's the difference?

Re: Wikimedia is moving to Gitlab

#123

Post by zeeZ »

jancsika wrote: post #114
zeeZ wrote: post #102

Earlier quoted context omitted.

In general settings, you can check "Public" under "Restricted visibility levels". According to the blurb, "selected levels cannot be used by non-admin users for groups, projects or snippets". Is that not what you want with #2?

It's what I want for #2, but it has the unfortunate side-effect of restricting visibility for my main public repo. My #1 goal above is for people to be able to clone from my main repo without logging in.

I see. And as soon as you make the repo public you end up with public issues again, unless you restrict them to project members...

And a workaround of auto syncing just the code to a public repo where issues and stuff is disabled isn't available natively in CE.

Re: Wikimedia is moving to Gitlab

#124

Post by wizzwizz4 »

saxonww wrote: post #112
parliament32 wrote: post #87

Earlier quoted context omitted.

It's not open source, at best they ship you a locked down VM image to run yourself. Edit: Confirmed, "GitHub Enterprise is delivered as a virtual appliance that includes all software required to get up and running. The only additional software required is a compatible virtual machine environment." https://enterprise.github.com/faq

This is not true, they publish the code at https://gitlab.com/gitlab-org/gitlab . If you want to use premium features, you do have to pay to unlock them, and depending on your deployment you would need to get the gitlab-ee image instead of the gitlab-ce one.

We're talking about GitHub.

Re: Wikimedia is moving to Gitlab

#125

Post by mxskelly »

frenchyatwork wrote: post #84
mxskelly wrote: post #55

Earlier quoted context omitted.

Oh right yeah pressure from China, like what got youtube-dl entirely removed... Oh wait no that was the US government.

It's naive to believe that Microsoft would stand up to the CPP and not the US government.

It's more naive to treat the CCP like some kind of horrible boogeyman who wants to destroy freedom while completely ignoring the US's own issues.

Re: Wikimedia is moving to Gitlab

#126

Post by sytse »

ran3824692 wrote: post #109
sytse wrote: post #92

Earlier quoted context omitted.

At GitLab Inc. we have a Trust and Safety team https://about.gitlab.com/handbook/engineering/security/opera... that prevents spam. So far that functionality has lived in separate repositories from the core codebase since few people needed it, the cycle time was quicker, and it is an advantage to not have the spammers see the code. If there is strong interest in collaborating on this I'm sure they will be happy to eng…

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

I think the code of this problem is that it is hard to identify if a user is a bot or a human. I've not seen any elegant free solutions to this.

Re: Wikimedia is moving to Gitlab

#127

Post by ran3824692 »

ognarb wrote: post #90
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…

Strange I never saw this behaviour on our Gitlab instance invent.kde.org.

invent.kde.org uses the nonfree google Recaptcha, that prevents it mostly. Not very nice for KDE to make people run nonfree software blob in their browser that gives up their freedom, gives up their privacy to google and trains Google's proprietary machine learning models.

Re: Wikimedia is moving to Gitlab

#129

Post by TonyTrapp »

zeitg3ist wrote: post #47
vorpalhex wrote: post #11

Earlier quoted context omitted.

Wikimedia is very cautious in making changes because they take very seriously the values of sustainability and predictability. That they are moving from Gerrit to Gitlab is a blow against Gerrit and a boon for Gitlab (assuming it goes well).

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…

None of that was forced on anyone, though. Everything you mention are purely optional components. I think it makes sense for them to explore new technologies like that while still keeping their general requirements conservative.

Re: Wikimedia is moving to Gitlab

#130

Post by depressedpanda »

js2 wrote: post #12
epistasis wrote: post #4

Earlier quoted context omitted.

What advantages do you see in Gerrit? Do they require a lot of experience in order to be realized?

I much prefer the model of force-pushing your development branch to create change sets. It lets you more easily see how development evolves in response to feedback. And the final state of the branch which gets merged leaves all the in-progress work that no one cares about behind only in Gerrit. With Github/lab's model, if you force push your PR, you lose the ability to view its previous state and diff against that. A…

But you don't force push with Gerrit?

Just update your change set, then push to refs/for/ again.

Post reply on HN