Live data from Hacker News

Almost Everything We Do Will Be Open

about.gitlab.com

71–80 of 208 posts

Re: Almost Everything We Do Will Be Open

#71

Just saw that gitlab now offers free hosting, you only pay for support (only if you want it). Do enough people really pay for support in order to keep gitlab from going under? Free software is one thing, but free hosting? It just blows my mind how they can offer such a thing.

We do not make substantial money with GitLab.com. It gives us the possibility to run GitLab on a very large scale. This helps us finding performance and scaling issues that otherwise would go unseen. In short, it allows us to make GitLab even better.

If this is really the case and your business model is aligned with this, there's nothing else to say, except "Congratulations!".

I didn't know that this can go so well for end-users in such a competitive environment. I hope I hear more arguments like these from other tech companies.

How do you call this model? I guess freemium doesn't match with how you make the benefit out of the website.

Re: Almost Everything We Do Will Be Open

#72
GitLab Enterprise user here. GitLab's open-source policy is one of the major reasons we chose it (along with self-hosting and fairly modern, built-in continuous integration), but the GitLab community could use some additional design and documentation effort.

Things that almost make me want to switch back to GitHub:

- GitLab is really hard to look at. All of our devs are having trouble visually locating comments in diffs. We're always scrolling through the left-side menu looking for the issues tab. It's hard to visually differentiate between items like comments in merge requests. Our eyes just can't find and follow things. Even BitBucket looks better.

- GitLab-CI has poor documentation on runners, and a rather buggy test runner registration process that doesn't provide any debugging output and produces false positives quite often.

- GitLab-CI has no unconditional cleanup directive, like CircleCI does... but if you're re-using a test runner instead of tearing down the server each time, unconditional cleanup is the one thing you need. And no, the Docker executor doesn't solve this because we don't want to test our Docker containers inside Docker.

- CI is based on commit IDs. You can't run particular CI events on merge requests. For example, this means no way to run integration tests on merge requests.

- Typography could be improved. When you're looking at the issues page all day, this is quite noticeable.

- Slack integration is not great; it dumps links to "GitLab Enterprise Edition" instead of useful commit/changeset stuff like GitHub does.

If the community/GitLab can focus on putting on some of the design polish and service integration polish that GitHub has, GitLab would be a total winner for us, long-term.

Re: Almost Everything We Do Will Be Open

#73

Good timing. Recently installed Gitlab Community edition on DigitalOcean (one click install) and so far loving it. Some issues: - Does it have a default task management tool or we need to integrate a 3rd party ? Couldn't find it in the forums yet - The UI is a bit clunky in terms of navigation. For example, being able to move from the homepage level to specific project back and forth is a bit confusing. Would love a…

Happy to hear! > Does it have a default task management tool or we need to integrate a 3rd party ? Couldn't find it in the forums yet You can use Issues, which comes in every project and can be linked all throughout your GitLab instance. They also integrate with merge requests and can be used 'Kanban' style by using milestones. See our own for GitLab's issues: https://gitlab.com/gitlab-org/gitlab-ce/issues You can al…

Some proofreading issues related to the CI webpage (https://about.gitlab.com/gitlab-ci/). ). They're minor and easy to fix but I think they would help regarding sales:

-> Multi-platform since you can executes builds on Unix, Windows and OSX.

-> Stable because the GitLab CI is on a different machine that(n) the ones that perform builds.

Also the whole phrasing is a bit weird, I'd change it to:

Key feature: description.

The way it is now those phrases seem a little clunky and unnatural.

A totally separate issue, what are the limitations for the CI stuff? Build per day/per OS/whatever?

Re: Almost Everything We Do Will Be Open

#74
post #34

We've been enjoying GitLab for quite some time now, but I have to say with every new release they always seem to break something critical for us, there seems to be far too many regressions and many of them are not communicated evening with their paying customers - for example the latest one that's been causing us grief: https://gitlab.com/gitlab-org/gitlab-ce/issues/1974

Not to be rude, but isn't their software open source? Can't you try and patch it yourself?

If I've read his post correctly he's a paying customer. Surely that has to count for something :)

Re: Almost Everything We Do Will Be Open

#75

GitLab Enterprise user here. GitLab's open-source policy is one of the major reasons we chose it (along with self-hosting and fairly modern, built-in continuous integration), but the GitLab community could use some additional design and documentation effort. Things that almost make me want to switch back to GitHub: - GitLab is really hard to look at. All of our devs are having trouble visually locating comments in di…

Thanks for the feedback, we really appreciate it!

The quick reply to your comments is: we're working on almost all of it.

> - GitLab is really hard to look at. All of our devs are having trouble visually locating comments in diffs. We're always scrolling through the left-side menu looking for the issues tab. It's hard to visually differentiate between items like comments in merge requests. Our eyes just can't find and follow things. Even BitBucket looks better.

We're working hard on this and focus more and more of our development capacity to this.

> - GitLab-CI has poor documentation on runners, and a rather buggy test runner registration process that doesn't provide any debugging output and produces false positives quite often.

There are a lot of improvements coming in this field. Especially the integration and setup of runners is going to be easier. We're hoping to make this a zero-step setup thing. Same with documentation. Our new GitLab CI maintainer Kamil has been spending a lot of time on writing documentation.

> - GitLab-CI has no unconditional cleanup directive, like CircleCI does... but if you're re-using a test runner instead of tearing down the server each time, unconditional cleanup is the one thing you need. And no, the Docker executor doesn't solve this because we don't want to test our Docker containers inside Docker.

This is interesting, I'm passing it onto Kamil.

> - CI is based on commit IDs. You can't run particular CI events on merge requests. For example, this means no way to run integration tests on merge requests.

This is be interesting to look at. I'm not sure whether we have something like this in the planning, but I'm taking note.

> - Typography could be improved. When you're looking at the issues page all day, this is quite noticeable.

We're worried about adding page load by including typefaces. We might change our minds on this. What OS are you using? Would Roboto work, for instance?

> - Slack integration is not great; it dumps links to "GitLab Enterprise Edition" instead of useful commit/changeset stuff like GitHub does.

We welcome contributions to improve it. This is not a focus at the moment, but considering the popularity of Slack, we can definitely have a look at this.

Re: Almost Everything We Do Will Be Open

#76
post #19

Decided to switch to gitlab when I realized github refused to release their tools on Linux even though according to stackoverflow statistics Linux users make up over 20% of programmers, matching the number of OS X programmers. It's unfortunate that they make a living off open source software created by a lead Linux developer but they act like Linux doesn't even exist. Not a big deal though, the userbase on github is…

> Not a big deal though, the userbase on github is worse than facebook or 9gag.

Found the grumpy linux user ;)

Re: Almost Everything We Do Will Be Open

#77
post #27

Earlier quoted context omitted.

Is bitbucket considered not a competitor? I've found it quite suitable for anything github does, though I'm at max a 5 person team.

BitBucket is far superior to GitHub. It's not even a question.

Sometimes I end up on Bitbucket pages for a repo, and have a hard time locating how I can view the directory tree of the repo. I wouldn't call this "superior." It's not unfixable, but definitely not superior.

Re: Almost Everything We Do Will Be Open

#78
post #77

Earlier quoted context omitted.

BitBucket is far superior to GitHub. It's not even a question.

Sometimes I end up on Bitbucket pages for a repo, and have a hard time locating how I can view the directory tree of the repo. I wouldn't call this "superior." It's not unfixable, but definitely not superior.

Precisely the one reason I can't bother to use it for real: I'd like the source tree to be the default view.

Re: Almost Everything We Do Will Be Open

#79
post #73

Earlier quoted context omitted.

Happy to hear! > Does it have a default task management tool or we need to integrate a 3rd party ? Couldn't find it in the forums yet You can use Issues, which comes in every project and can be linked all throughout your GitLab instance. They also integrate with merge requests and can be used 'Kanban' style by using milestones. See our own for GitLab's issues: https://gitlab.com/gitlab-org/gitlab-ce/issues You can al…

Some proofreading issues related to the CI webpage ( https://about.gitlab.com/gitlab-ci/ ). ). They're minor and easy to fix but I think they would help regarding sales: -> Multi-platform since you can execute s builds on Unix, Windows and OSX. -> Stable because the GitLab CI is on a different machine tha t (n) the ones that perform builds. Also the whole phrasing is a bit weird, I'd change it to: Key feature: descri…

Thanks, fixed here: https://gitlab.com/gitlab-com/www-gitlab-com/commit/a70f6693...

Regarding limitations: at this point there are no limitations.

Post reply on HN