Live data from Hacker News

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

231–240 of 325 posts

Re: Dear open-source maintainers, a letter from GitLab

#231
post #126

Earlier quoted context omitted.

Don't be cruel to animals. I'll ship you the 256GB of ram personally, email me at sytse at company domain.

By the way, I don't want to troll you, but at my company we use Gitlab 6 self hosted version and I wasn't able to do a simple git push origin master the repo I held in my machine was barely 5MB and still remote server closed connection HTTP 500 I solved it by increasing the POST buffer. I never had this issue with github, maybe you can check why it was an issue with gitlab? it might help to advance your product!

Thank you for feedback. We improved git push a lot since version 6. So when you update to recent version it should not be a problem anymore.

Re: Dear open-source maintainers, a letter from GitLab

#232
post #28

Earlier quoted context omitted.

We are dealing with a lot of sensitive data and code which is legally not allowed to physically leave our group and GitLab is in my opinion the best open source choice for that. I feel its community edition is up to par with github in most aspects and it a was a change towards the better from our previous svn based solution (Redmine)

A good friend of mine likes to run https://gogs.io/ .. I havent used it heavily but Ive been impressed so far.

I've been using Gogs for personal use for a while. I love its speed and its simplicity.

That said, it's probably not a good fit for most businesses at this point. It's relatively new, and mostly maintained by a single developer, who spent the last summer on vacation.

He's very active when he's around, and almost always working on improving Gogs, but there's a lot of people with features requests (the issue that's always getting comments today is for opening pull requests across branches within a single repository -- i.e. not forking.)

Re: Dear open-source maintainers, a letter from GitLab

#234
post #42

Earlier quoted context omitted.

We are dealing with a lot of sensitive data and code which is legally not allowed to physically leave our group and GitLab is in my opinion the best open source choice for that. I feel its community edition is up to par with github in most aspects and it a was a change towards the better from our previous svn based solution (Redmine)

There's also Stash (now renamed to BitBucket Server (edit: fixed name, as pointed out in the reply)). It does not include some of the features (such as issue tracking), and I think rightly so. I haven't used GitLab for maybe 2 years now, so I can't compare the two.

To be clear, it doesn't support issue tracking because it is an Atlassian project. Issue tracking is done through Jira, another product they offer.

Re: Dear open-source maintainers, a letter from GitLab

#235

I still don't know how I feel about GitLab. My initial reaction was that they were an underhanded, cheap knockoff of GitHub. It felt kind of dirty, like they were stealing GitHub's thunder and giving it away for free. Then they started charging for enterprise features and turned it into a business, which felt even weirder. And then they raised a lot of money, which kind of made them seem more legitimate. And now this…

> I still don't know how I feel about GitLab. My initial reaction was that they were an underhanded, cheap knockoff of GitHub. It felt kind of dirty, like they were stealing GitHub's thunder and giving it away for free.

Seems like they were just following in the footsteps of one of Open Source's great prophets: https://en.wikipedia.org/wiki/Richard_Stallman#Events_leadin...

Re: Dear open-source maintainers, a letter from GitLab

#236

Earlier quoted context omitted.

Maybe just support hg-git? All someone has to do is write some tests for Gitlab, and then you are all set?

hg-git already works with gitlab, doesn't it?

I was having problems even cloning using hg-git + ssh.

Re: Dear open-source maintainers, a letter from GitLab

#237

I remember GitLab. They interviewed myself and a bunch of my colleagues to test the salary waters here in the Bay Area and hired nobody because we were all "overpriced", with several being underpaid for the area. If you want the talent you need, especially in the Bay Area, you have to pay more than what the average developer makes in Amsterdam. I want to like GitLab, but I just can't get that bad taste out of my mout…

Well, Bay Area salaries have gotten way out of hand in the past few years, mostly due to the cost of living there, but that is besides the point.

Since we are a remote company we have the luxury to be able to hire amazing engineers from all over the world. Paying 1 Dev salary in the Bay Area is almost the same as paying 2 salaries in Europe, or even 5 in Latin America. Talented people can be found everywhere, not just the bay area.

And having a global workforce also allows us to have the best people with a vast variety of backgrounds, which also contributes to our culture.

Re: Dear open-source maintainers, a letter from GitLab

#238
post #183

I've recently made an iOS App that integrates with GitLab. The people at GitLab have been incredible, they respond to my issues, improve the API with every release, I didn't expect this level of awesomeness when I started the project. What's great about GitLab, there's a release on the 22nd of each month, so you can depend on pretty much continual improvement. Even if you don't think GitLab is suitable for your Open…

Just bought the app from these recommendations. It is beautifully made. Nice work :)

Re: Dear open-source maintainers, a letter from GitLab

#239

Any chance you can support Mercurial? There was a highly voted issue that I saw sometime back.

If you're looking for Mercurial try out RhodeCode, it support all the Mercurial specific workflows like phases etc. RhodeCode actually supports Git, Mercurial, and Subversion.

Is Rhodecode completely open source like Kallithea?

Re: Dear open-source maintainers, a letter from GitLab

#240
post #226
post #224

Earlier quoted context omitted.

Well, I can understand that having a business model which actually is stable and makes around FLOSS is hard, so I can tolerate a lot of wiggling around the edges of freedom. However, what I cannot tolerate is freedom of my data. Our IT guys are uneasy to installing supported version of GitLab internally (aside from the small question of money), because they are afraid that once we install EE version, we are locked in…

Downgrading from EE to CE is officially supported. You can find the docs here: http://doc.gitlab.com/ee/downgrade_ee_to_ce/README.html

This is just amazing, you're awesome, thank you Gitlab team.
Post reply on HN