Earlier quoted context omitted.
They're selfhosting.
You can self host GitHub too
Which costs $21/user/month versus $0 for the free plan and $4 for the team plan. That's a steep price increase.
Wikimedia is moving to Gitlab
101–110 of 408 posts
Re: Wikimedia is moving to Gitlab
#102Anyone 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…
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?
Re: Wikimedia is moving to Gitlab
#103This 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…
Do you think that gitlab will ever add inline diff comments? I don't know if it would even be feasible to add to gitlab
Re: Wikimedia is moving to Gitlab
#104Earlier quoted context omitted.
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.
1. Create user account 2. Create spam content (snippets, profile, etc.) 3. Get spam content search indexed 4. Profit
a free user sign up is not going to prevent scraping...
Re: Wikimedia is moving to Gitlab
#105Earlier quoted context omitted.
No, robots.txt is for well behaving bots like bing bot and google bot, not bots that will spam your forums (and Git repo apparently).
But if the issue is SEO bots then robots.txt would block the search engines thus meaning the spam content is of no importance (it's effectively private) and doesn't cause issues for the main sites SEO (nor help the spammers).
To be honest, I'm not certain of the purpose of the spam.
Some portion of it would end up in the search results, sure.
But I don't know if there's some secondary benefit to, say, a casino showing a link coming from my site even if my site has a robots.txt saying that the address for that link isn't to be directly indexed.
Is there such a benefit? If not then I'll just set up the robots.txt and observe whether that does indeed solve the problem. But I'd much prefer to just set up the permissions I know I want on my own running instance than spend time making inferences about the reasons bots are abusing my instance's inputs.
Re: Wikimedia is moving to Gitlab
#106Anyone 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.
Because it's Microsoft FUD.
Re: Wikimedia is moving to Gitlab
#107Earlier quoted context omitted.
1. Create user account 2. Create spam content (snippets, profile, etc.) 3. Get spam content search indexed 4. Profit
a free user sign up is not going to prevent scraping...
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
Re: Wikimedia is moving to Gitlab
#108Microsoft will slowly kill github
Depends. MS used to have its own code hosting service (Codeplex I believe), and it wasn't that bad, but Github was more "social". I think it's mostly a question of how independent Github will be under MS. Now to be fair, MS has good services. Azure is nice, and office 365 is pretty good.
They might make money off if it, but I believe GP was referring to github's prominence as the home of so many free software projects.
Re: Wikimedia is moving to Gitlab
#109Anyone 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…
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/-/issues/46548
Re: Wikimedia is moving to Gitlab
#110Anyone 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.
If you allow new users to create user profiles with links, and those user profiles are visible to Google, spammers will create a bunch of new user accounts and fill them with spam links.
The easiest way to prevent this is to block Google from seeing user profiles by requiring login to see the profiles.