Live data from Hacker News

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

191–200 of 325 posts

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

#191
post #187
post #70

This attempt by the Gitlab folks to ride the Github dissatisfaction wave seems a little low-brow. Why respond to a letter that's not addressed to you? I would have preferred them to simply post an honest "Why you should migrate from Github to Gitlab" article. The tone just seems a little devious to me. By the way, we're using self-hosted Gitlab at work and we love it. This isn't a knock against the actual product. In…

I think GitLab is a reaction to the problems GitHub has, to me it IS the response to the letter, though maybe not the one you'd first expect!

Yes, that's sort of the point I'm (badly) trying to get across. I think the product speaks for itself. That said, I may have misinterpreted the tone of the article.

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

#192
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.

I started looking into GitLab and Phabricator around August/September 2014 for my company. My criteria was primarily based around something to assist with code review. Ultimately I went with Phabricator for several reasons:

1. Supports Mercurial - our repositories are currently in mercurial, and using any other tool would require switching to git (which we seriously considered while looking at tools).

2. Simple to maintain - if you have experience setting up other web applications based around LAMP, this is essentially very similar. The web interface even indicates setup issues to admins, from things which can cause issues to performance configurations in things such as MySQL and PHP.

3. The code review interface was more intuitive for myself and other engineers. From the command-line tool (Arcanist) to how it's conveyed to the user in the web interface. It did take a little time to fully comprehend and implement the process for using, but since implementing in Feb. of last year, after around 4 months we had near 100% adoption by the engineering department. The GitLab/GitHub interfaces I've found to not be organized intuitively -- the lifetime of an issue/changes seems (seemed?) more social-based and intermized where in Phabricator an Issue/Task is almost separate from the changes which can go into it, though they reference eachother easily.

>Also, do they pride themselves for writing this in PHP? I consider this an anti-feature, but this might be highly opinionated.

I had the same reaction at first (thought I wouldn't say it's pride?). In fact the first time I looked at Phabricator (~2012) I totally dismissed it for three reasons:

1. Written in PHP

2. Mentions pokemon on the front page

3. Marketed as "collection of open source web applications"

These led me to believe that it was at most some PHP glue some students hacked together to get different unrelated applications to play together. This conclusion is entirely wrong. I've since changed my mind about PHP - biased from earlier experiences there's no reason to think a reliable/stable application couldn't be built on it. Phabricator (I believe) started as an internal application at Facebook which has since become its own company. The code is very well organized (I've contributed some small changes), and there are some very bright people working on the project - I get the vibe that they genuinely want to solve the right problems rather than checking features off a list. There are very few dependencies on other libraries unless you specifically decide to enable extra features, and even then there's some support/documentation there to assist. Despite the light-hearted humor (see pokemon) that is a staple of the software (unless you enabled serious-business mode), the project is designed and developed by highly capable, quality professionals.

I couldn't have been happier going with Phabricator over GitLab.

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

#193

I've been using GitLab instead of GitHub recently for all my new projects and honestly there's nothing worse than GitHub and a few things are better - like having protected branches and master by default in it -, private respositories etc. That being said, what both GitHub and GitLab are missing is actually becoming a "social network" or maybe more an active network. There are tons of interesting projects that pops u…

https://github.com/explore/subscribe

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

#194
post #82
post #70

This attempt by the Gitlab folks to ride the Github dissatisfaction wave seems a little low-brow. Why respond to a letter that's not addressed to you? I would have preferred them to simply post an honest "Why you should migrate from Github to Gitlab" article. The tone just seems a little devious to me. By the way, we're using self-hosted Gitlab at work and we love it. This isn't a knock against the actual product. In…

> This attempt by the Gitlab folks to ride the Github dissatisfaction > wave seems a little low-brow. There's a github dissatisfaction wave? Anyway, opening sentence of gitlab's open letter: "The letter of GitHub’s open source community is clearly not addressed to us, but we’re thinking a lot about the issues that were mentioned in it." Does that cover your concerns? I think if github was the free software entity, an…

"Wave" might be too strong a word, but I've seen three or four posts on HN in the last few days that were pretty critical of Github's closed source nature and insufficient transparency.

I'm not sure why offering a free software edition somehow gives you a pass. Both Github and Gitlab are commercial entities as far as I know.

Anyway, my concern wasn't a big deal, I was just a bit taken aback at the opportunism. In retrospect, I think my reaction was a bit overblown.

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

#195
post #70

This attempt by the Gitlab folks to ride the Github dissatisfaction wave seems a little low-brow. Why respond to a letter that's not addressed to you? I would have preferred them to simply post an honest "Why you should migrate from Github to Gitlab" article. The tone just seems a little devious to me. By the way, we're using self-hosted Gitlab at work and we love it. This isn't a knock against the actual product. In…

It reminds me of the way Google and others try to glom their brand onto cultural events.

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

#196
post #134

Earlier quoted context omitted.

We'll not support Mercurial, this would be an additional layer of indirection and limit us to features that are supported in both Git and Mercurial.

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?

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

#197

If GitLab plays their cards right, they can take the market from github. That, in my book, will be good because unlike github, we can all contribute to making GitLab better. The only question left is if your servers are powerful enough to run gitlab. Maybe I'll sacrifice a goat for some new server hardware and 256GB of ram.

Why sacrifice any ol' goat when what you need is [a] ram?

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

#198
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 projects and a vastly better UI than GitLab (though that isn't saying much with how awful GitLab's UI is).

I'm eager to see how GitHub evolves in the future with GitLab as a competitor, as GitLab has a lot of nice features (built-in CI, etc).

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

#199
post #154

Earlier quoted context omitted.

I don't know if that would apply to GitLab too, but maybe consider switching from the CE / EE model to just one "product" and a free for non-commercial model? Like e.g. http://3t.io/mongochef/download/ does it? I like that model way more than a feature-reduced version.

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?

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

#200
post #111
post #9

With VideoLAN, we're not on github, but I believe we fit the 'large open source project' description. We host VLC, FFmpeg, x264 and quite a few related libraries. For VLC and all related VideoLAN projects, we're moving to our own instance of GitLab hosted on our infrastructure. And to be honest, it's quite good, but a few stuffs are ridiculously limited, to the point that some people in the community are resisting th…

We would love to help you to host VideoLAN on a on-premises GitLab instance. Thanks for raising the issues you did. 1. Our EE version has the function share project with other groups http://doc.gitlab.com/ee/workflow/share_projects_with_other_... If this is essential for you we'll give you a free lifetime license for GitLab EE. 2. You can add custom labels on issues and the searches can be stored in urls that you can…

> If this is essential for you we'll give you a free lifetime license for GitLab EE.

While I get the sentiment, I don't think this helps. If you want to help the Open Source community, give us what we need in the form of open source. If I don't care about vendor lock-in I can go ahead and use GitHub. GitLab counts because its open source, and its open source version is the only thing the open source community should care about.

Post reply on HN