Live data from Hacker News

GitLab 8.15 Released

about.gitlab.com

21–30 of 117 posts

Re: GitLab 8.15 Released

#21
I'm curious how you guys build features for EE. Is it a completely separate Rails project you handle manually to keep base features in sync with the community edition?

EE is open source but requires a license. Do you just trust companies won't download the source code and run it. Do you have heartbeat code injected somewhere to ping servers that are running EE to homebase?

I'm thinking of starting a project, charge money but also open-source it. Curious what your strategies are, especially since the project is still greenfield.

Thanks!

Re: GitLab 8.15 Released

#22

I'm curious how you guys build features for EE. Is it a completely separate Rails project you handle manually to keep base features in sync with the community edition? EE is open source but requires a license. Do you just trust companies won't download the source code and run it. Do you have heartbeat code injected somewhere to ping servers that are running EE to homebase? I'm thinking of starting a project, charge m…

EE (Enterprise Edition) and CE (Community Edition) are two separate projects indeed. Before each release, CE is merged to EE manually.

We encourage you to start a project, try to monetize it and also open-source it. The benefits of open sourcing are huge. Take a look at some of blog posts about that:

[0]: https://about.gitlab.com/2016/07/08/7-myths-about-open-sourc...

[1]: https://about.gitlab.com/2016/07/07/trends-version-control-i...

Re: GitLab 8.15 Released

#23

I'm curious how you guys build features for EE. Is it a completely separate Rails project you handle manually to keep base features in sync with the community edition? EE is open source but requires a license. Do you just trust companies won't download the source code and run it. Do you have heartbeat code injected somewhere to ping servers that are running EE to homebase? I'm thinking of starting a project, charge m…

>I'm curious how you guys build features for EE. Is it a completely separate Rails project you handle manually to keep base features in sync with the community edition?

It's the same codebase with some additional code. Every few days we merge CE into EE[1], which always ends up with some merge conflicts – though those are getting better as we learn to engineer around them – and its own problems, but it works pretty well. I think this is a great system, even with its drawbacks, if you want to keep the base product as FOSS. Just be aware of the problems you'll likely run into, and avoid implementing any EE-only features that will cause crazy merge conflicts.

>EE is open source but requires a license. Do you just trust companies won't download the source code and run it. Do you have heartbeat code injected somewhere to ping servers that are running EE to homebase?

It has a built-in system for uploading the license and verifying that the license covers the users of the instance. The license (as in the copyright license) says that users cannot use EE if they get around that. We don't have many cases of piracy as far as we know, and don't care too much. No major enterprise customer would realistically pirate software since that'd be a legal nightmare if they were caught.

>I'm thinking of starting a project, charge money but also open-source it. Curious what your strategies are, especially since the project is still greenfield.

Best of luck! It's awesome to see others try to go for this kind of model, I hope it works for you :)

Some others to look at: Sentry, Mattermost, and Code Climate.

[1]: Example of a CE-to-EE merge request: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/991

Re: GitLab 8.15 Released

#24
As a paying gitlab ee customer, we love to use gitlab. I just have one gripe with review apps. We would really like you to open it up with an API.

Allowing us to create the infrastructure outside of gitlab-ci and setting the reviewapp url/domain etc using the API would be extremely valueable for us, as we are stepping off of the gitlab-ci, but would very much like the UI interface upgrades review apps provides.

We are stepping off of Gitlab CI because of: * Only a single pipeline allowed per repository. We have a monorepo as we have a lot of small artifacts that make no sense to split out to multiple repo's and have to manage using gitsubmodules or having a separate code review process (we use merge requests a lot!) * Gitlab-ci's "stages" and not allowing dependencies on cross-stage is not helpful * No "skipped" status that can be supplied during the pipeline. E.g., we want to ignore changes to our documentation .

Re: GitLab 8.15 Released

#25

@Gitlab: The features are great but the interface setup is shocking. That whole video assumes you have a K-cluster going already, and is a maze of this-thing, that-thing, auth-thing, copy-thing, etc. Have you guys ever tried interviewing users who are new or maintaining a Gitlab instance over major version upgrades? It's painful. The 'quick fix' for setup these days is supposed to be to use a docker image... but the…

Thanks for the honest feedback, it's genuinely useful for improving the product. Out of curiosity, why use the Docker image over our Omnibus package? Omnibus is generally what we recommend, but if that's not good enough we'd love to know how it can be improved.

Even if I trusted it not to munge other things (doubtful), IIRC omnibus does not support my distro (Gentoo), and setting up another distro I have to (remember to) maintain just to support one application does not appeal medium term versus using a popular docker image which has done that for me already in a pre-tested fashion and should handle maintenance smoother.

Basically I'm at this point: 'what's the easiest self-contained box to run and maintain', with conditions 'I have an IP but it's not dedicated (ports 22/80/443 unavailable)' and 'there may not be existing DNS/SSL for this server but I can set it up' and 'SMTP from this IP is not desired/desirable, but I have an existing offsite ISP allowing relay with credentials'. This doesn't strike me as particularly weird, except that in the latter case Google is not an option (GFW'd from China).

Re: GitLab 8.15 Released

#26

@Gitlab: The features are great but the interface setup is shocking. That whole video assumes you have a K-cluster going already, and is a maze of this-thing, that-thing, auth-thing, copy-thing, etc. Have you guys ever tried interviewing users who are new or maintaining a Gitlab instance over major version upgrades? It's painful. The 'quick fix' for setup these days is supposed to be to use a docker image... but the…

Thanks for the honest feedback, it's genuinely useful for improving the product. Out of curiosity, why use the Docker image over our Omnibus package? Omnibus is generally what we recommend, but if that's not good enough we'd love to know how it can be improved.

Is there a Omnibus package for Kubernetes (perhaps a Helm package?) I'd be very interested in that.

FWIW: I ran GitLab at my previous company (2yrs agoish) because GitHub was a non-starter for political reasons. We loved it! Keep rocking.

Re: GitLab 8.15 Released

#27
This is nice and all but what about page load times? It can have all the bells and whistles but if you have to wait a minute for just one page to load, it's unusable.

Re: GitLab 8.15 Released

#28
post #27

This is nice and all but what about page load times? It can have all the bells and whistles but if you have to wait a minute for just one page to load, it's unusable.

We've spent quite a bit of time this year improving performance, GitLab.com is still slower than it should be but it's a lot better now than it was in January. Self-hosted instances that meet the recommended specs are already fairly performant, though we're always working to improve things regardless.

As mentioned in the blog post, this release we decreased page size a lot (from 1800kb to 718kb for a given Merge Request).

We're also working on moving to our own infrastructure, the reasoning behind that move is described here: https://about.gitlab.com/2016/11/10/why-choose-bare-metal/

EDIT: Strike that, we've decided against moving to bare metal for now due to the complexity. I somehow missed that decision.

Re: GitLab 8.15 Released

#30
I recently registered to try gitlab. I received unprecedented large amounts of spam from them daily with no unsubscribe button. I finally emailed them to stop the spam and they did but not completely I received more but had unsubscribe this time. Unsubscribed so lets see what happens. One more spam and I will close my account and never try them again

GitHub is great, does the job incredibly well, doesn't get in the way and have never been spammed (tip for you gitlab here).

[update] Please don't forget to downvote me for giving honest feedback :-)

Post reply on HN