Live data from Hacker News

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

201–210 of 325 posts

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

#201

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…

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)

You should also consider Apache Allura (https://allura.apache.org/), Fossil (http://www.fossil-scm.org/), Phabricator (http://phabricator.org/) and GitBucket (https://gitbucket.github.io/gitbucket-news/).

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

#202
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!

GitLab introduced a new web server (gitlab-workhorse) in 8.0 that's better at handling large HTTP requests. I would suggest upgrading (not just for that reason, there have been tons of improvements and security updates).

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

#203
post #87
post #74

Meanwhile, Phabricator has implemented all of these (and even more). Custom templates: https://secure.phabricator.com/book/phabricator/article/form... Votes: https://www.mediawiki.org/wiki/Phabricator/Tokens It's better in almost every aspect than GitLab and GitHub. See https://en.wikipedia.org/wiki/Phabricator for an (incomplete) list of open source projects using it.

As a quite disappointed user of Gitlab (due to issues raised here, e,g, CE vs EE and the Ruby infrastructure), has anyone had experience with both? I understand that Phabricator is a more "complete" solution, but how do they compare in the core features that they both share? Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.

A note - the Phabricator core team have been reticent in merging changes or features that they don't themselves depend on upstream. If you need anything that isn't offered out of the box or on the roadmap, be prepared to maintain your own fork of Phabricator indefinitely.

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

#204

I get why GitLab wrote this, but it seems like just a stab at GitHub. There seems to be a lot of hating on GitHub here, but I personally love GitHub (and we use GitLab at my current employer). I think GitLab is doing a great thing, and I appreciate that their community edition is free and open source, but GitHub has been able to provide an invaluable service. They have a great community that facilitates open source p…

It is a stab and tbh Im glad they took the opportunity. There are few times when a product can be marketed to such effect for as little cost. What they did was show everyone how awesome they are and how stagnent Github is. Github can easily change but most of their decision making is done behind the scenes.

Github grew popular because it was popular. Maybe thats worth something but long term they must adapt just like Gitlab

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

#205
post #33

I chose Gitlab for my former company over GitHub Enterprise because we wanted an on-prem solution, and it worked well enough for ~200 folk. We did have to tweak (and occasionally break) a few things, since quite a few people suffered from NIH syndrome and wanted things done "the right way". In general, I liked it, but it always irked me that its Ruby underpinnings made it hard to upgrade/migrate stuff (we basically j…

I thought you could do on-prem with GitHub Enterprise?

GitHub Enterprise was essentially a closed VM that did not allow us to do the sort of customisation we needed - nor, most crucially, mount the git repos from our enterprise SAN.

Gitlab allowed us to do that without any hassle, even running inside an LXC container.

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

#206
post #120
post #33

I chose Gitlab for my former company over GitHub Enterprise because we wanted an on-prem solution, and it worked well enough for ~200 folk. We did have to tweak (and occasionally break) a few things, since quite a few people suffered from NIH syndrome and wanted things done "the right way". In general, I liked it, but it always irked me that its Ruby underpinnings made it hard to upgrade/migrate stuff (we basically j…

I'm sorry to hear you're not satisfied with GitLab and I would love to know more. 1. What things did you have to tweak? 2. Did you try our Omnibus packages for upgrades? It should be just apt-get upgrade https://twitter.com/J_Salamin/status/687884326629937152 3. What features of EE belong in CE in your opinion?

1. For starters (besides other internal stuff), we were the guys who needed Shibboleth support. You might recall there were a few pull requests from a colleague of mine regarding that :)

2. No, we had to tweak the source, so I don't think the packages were useful.

3. Static pages, hooks and merge approvals would be right at the top of my list. Audits would be nice to have, but we figured out how to do that on our own.

Also, issue handling needs some improvement. We just couldn't map our Trac workflow to it - but that's a fairly longer story, and it would probably be the same if we used GitHub.

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

#207

I get why GitLab wrote this, but it seems like just a stab at GitHub. There seems to be a lot of hating on GitHub here, but I personally love GitHub (and we use GitLab at my current employer). I think GitLab is doing a great thing, and I appreciate that their community edition is free and open source, but GitHub has been able to provide an invaluable service. They have a great community that facilitates open source p…

Yeah, it's bit of a stab. I'm really curious to see how GitHub responds (if they respond). A lot of good could come out of this even if it takes some competition to force some of that.

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

#208
post #28

Earlier quoted context omitted.

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

I wonder why they advertise the "platform"/implementation language so clearly (in this case Go). It shouldn't matter for the users? I get sceptical, as if the only reason they exist is to provide the same service but in a new implementation.

Performance. That thing is _fast_ when compared to a Ruby-based stack.

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

#209
post #154

Earlier quoted context omitted.

We considered that but we value having a completely open source version for all projects more. For more information about how we see the difference between CE and EE please see https://about.gitlab.com/about/#stewardship

Have you ever considered using the AGPLv3 for the Community Edition, rather than the all-permissive MIT license?

I'm pretty sure they take outside contributions for CE, so if that was AGPL3 they wouldn't be able to use it in Gitlab EE, which sounds like shooting themselves in the foot.

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

#210
post #74

Meanwhile, Phabricator has implemented all of these (and even more). Custom templates: https://secure.phabricator.com/book/phabricator/article/form... Votes: https://www.mediawiki.org/wiki/Phabricator/Tokens It's better in almost every aspect than GitLab and GitHub. See https://en.wikipedia.org/wiki/Phabricator for an (incomplete) list of open source projects using it.

We had a go at Phabricator for code review. Suddenly, there were two opposing camps - those who hated it utterly and those who loved it and wanted to tweak the heck out of it.

Fortunately (for my team at the time, which was very resource constrained) those who hated it eventually won, but I, being kind of on the fence regarding it (wasn't keen on the UX, but liked the features), sort of wondered what would happen if someone improved the UX beyond the tipping point.

Post reply on HN