Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dear open-source maintainers, a letter from GitLab

about.gitlab.com

Post reply on HN
Print view View original

161–170 of 325 posts

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

#161

Post by agentgt »

pkd wrote: post #25
arihant wrote: post #20

> "Right now GitLab.com is really slow and frequently down. This is because of fast growth in 2015. We are working to improve it in the first quarter in 2016. For now please consider downloading GitLab and using it on-premise for a fast experience." Is this a joke? I mean for people looking for free private Git hosting, there is Bitbucket. This statement is like saying "free, but not really, really." The fact is if I…

Bitbucket allows only 5 contributors for free private repos. Gitlab allows unlimited. That is the major point of distinction, imo. Especially for medium sized projects.

Yes but Bitbucket has unlimited private repositories. So if your company has lots of projects compared to lots of people Bitbucket's pricing model is better.

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

#162

Post by jobvandervoort »

lmm wrote: post #47
jbk wrote: 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…

> Finally, it's not really related, since it's more a feature request, but we'd love to allow external people to fork our repos, but not create completely new ones (or have them validated) because we don't want to host any projects under the sun (there is github and gitlab for that). So far, you either allow both features or none of them. On a technical level that seems an impossible distinction to make. Someone want…

On your own instance, disallow creation or restrict of further projects. Ask people to use the 'Import any repo by URL' feature in GitLab on their own instance / GitLab.com.

We're planning to add cross-server merge requests in the future, which would make it that you don't have to host the forks yourself [0].

[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/4013

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

#163

Post by bitshepherd »

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 mouth.

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

#164

Post by ymse »

sytse wrote: post #154
lenovouser wrote: post #153

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

What about having a single product, and charging for a proprietary license + support? This may work better with GPL as many large orgs are allergic to it.

With MIT license, many sites probably just implement the branding changes etc in the CE product on their own.

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

#165

Post by DouweM »

agentgt wrote: post #161
pkd wrote: post #25

Earlier quoted context omitted.

Bitbucket allows only 5 contributors for free private repos. Gitlab allows unlimited. That is the major point of distinction, imo. Especially for medium sized projects.

Yes but Bitbucket has unlimited private repositories. So if your company has lots of projects compared to lots of people Bitbucket's pricing model is better.

GitLab.com is completely free, and has both unlimited private repositories and unlimited collaborators!

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

#166

Post by _yy »

marceldegraaf wrote: post #101
aaviran wrote: post #87

Earlier quoted context omitted.

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.

We've been using Phabricator for a few months, coming from private repos on Github.com. We initially liked it because it "ticked all the boxes" for the features that we needed from a source code and issue tracker. However, we ran into major issues along the way, basically because some of the concepts in Phabricator aren't compatible with our workflow. We decided to switch to Github Enterprise and haven't looked back…

> 1. Phabricator is actually a suite of different applications that do specific things (e.g. source code hosting, issue tracking, project management, ...). Although Phabricator ticked all our feature boxes, some of the components it ships with are very immature and/or don't get a lot of attention from the development team.

The features which aren't explicitly marked "experimental" work very, very well in my experience. Especially the code review part, which I find more pleasant to use than Gerrit.

> 2. For some reason the platform as a whole feels like a CRUD layer on top of a data model. The UI and various workflows in the applications are very tightly coupled with the underlying data model. I guess that makes it easy to develop and maintain the various core applications of Phabricator, but it doesn't make for a very user-friendly or usable product.

Have you got some examples? They're hiding the database pretty well IMO, and we haven't had many usability complaints that weren't about minor issues. Many of the experimental features are cumbersome to use though and we've turned off some of them again to avoid confusion.

> 3. We have ~150 internal repositories, we actively work on ~40 of them at any given time. The source code application doesn't seem intended for that many repositories (e.g. navigating to a specific repository is non-trivial)

Have you raised an issue about this? They're very responsive to issues encountered in real-world use and usually decide about feature requests by user demand. I do know that they're working on improving this - the "callsigns" will become optional, for example.

> 4. Phabricator has a fundamentally different approach to "pull requests". It works really nice, but only if you commit to using the Phabricator Way Of Doing Things. However, our team has been working on Github.com for years, and we're so used to the Github-workflow that we couldn't get used to the Phabricator workflow.

Their way of doing (or actually, not doing) pull requests is the most important feature of Phabricator. Their approach scales much better than the traditional style and is - in my opinion - the most important reason to choose Phabricator over Github-style tools. This might not matter for small projects, but in a company, it sure does.

Someone wrote it up quite nicely there: http://cramer.io/2014/05/03/on-pull-requests/

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

#167

Post by btmiller »

bitshepherd wrote: post #163

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…

Interesting. Yours is not the first account of a poor interview process with GitLab that I've heard. Even out of Texas, had a few colleagues that were very qualified and came out of it with a poor experience, to the point of changing their mind about wanting to work at GitLab.

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

#168

Post by _yy »

aaviran wrote: post #87
_yy wrote: 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.

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

I'd prefer it to be written in something else, too, but - the Phacility team are ex-Facebook developers. If anyone knows how to use PHP, it's them. They built their own, extensive web application framework on top of it (which is a remarkable achievement for itself). Phabricator is one of those rare examples that you can, in fact, write excellent code in PHP.

On top of that, they're running a bug bounty with generous payouts: https://hackerone.com/phabricator

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

#169

Post by _yy »

pekk wrote: post #118
VeilEm wrote: post #99

Earlier quoted context omitted.

> I understand that Phabricator is a more "complete" solution, but how do they compare in the core features that they both share? I think GitHub is prettier, but having tasks separate from repos and having tasks be as sophisticated as they are in Phabricator and having such a better pull requests system, it doesn't matter? GitHub has to dumb down the user interface on their product to appeal to the least common denom…

As a user of a self-hosted web service, how it's written affects details about the pain of deployment and administration. How it's written also affects whether it has satisfactory performance and how many nasty security problems are waiting to be discovered. Not everyone can afford to be completely blase about their source control system going down or getting defaced.

The Phacility guys know how to PHP. They used to work at Facebook. I don't like PHP either, but I trust the developers in this case.

Gitlab had its fair share of vulnerabilities, too, despite being written in Ruby. It's about the developers, not the language.

Have a look at their bug bounty program: https://hackerone.com/phabricator

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

#170

Post by profmonocle »

arihant wrote: post #61
DouweM wrote: post #27

Earlier quoted context omitted.

GitLab Community Edition is fully open source and completely free: https://about.gitlab.com/features/#community

I said if I wanted hosted option, then their only reliable option is $390 onboarding. Which is true. If I must go on-prem, then I might just use git directly? Meanwhile at Github, $7 gives me hosted private repos. It's free on Bitbucket if I limit collaborators. The biggest selling point of these services is peace of mind and knowing someone is taking care of the code when I sleep. Otherwise, Git has always been a FO…

> If I must go on-prem, then I might just use git directly?

Definitely. There's not much you can do with self-hosted GitLab that you can't do with pure git. GitLab just makes it easier, IMO. The main reason my company uses it is to restrict the master branch to certain people - doable with pure git, less effort with GitLab.

There's no reason we couldn't use GitHub for this (wouldn't cost much for a team our size), but my company prefers on-prem whenever practical for various reasons.

Self-hosted GitLab doesn't fit all the same uses as GitHub (I wouldn't use it for personal projects), but when it does fit it's great to have.

Post reply on HN