Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I have a single concern about GitLab. Looking at https://about.gitlab.com/direction/, I feel like there is way too much being labeled as EE only. I understand that GitLab has to make money to survive, however I see a lot of those features as things that are relevant to pure open source projects (private issues are something Open Source projects do actually need for security, think Chromium) and should probably be in CE. I absolutely love GitLab, but the roadmap has me certainly concerned.

The following features are most concerning:

https://gitlab.com/gitlab-org/gitlab-ee/issues/150 https://gitlab.com/gitlab-org/gitlab-ce/issues/4176

https://gitlab.com/gitlab-org/gitlab-ee/issues/112 (This one I am not as much concerned about, it's very complicated it seems, I can understand a bit why this would be EE)



Thanks for the feedback and for listing the features that you are concerned about.

The squash functionality is likely to stay EE only since it is similar to rebasing. Rebasing is EE only because larger enterprises are more likely to have this workflow.

Regarding the 'test the merge' functionality I've only heard requests from large organizations for that, can you detail the context in which you want to use it?

The code analytics is a typical enterprise feature in my view.

I think that the private/confidential issues in https://gitlab.com/gitlab-org/gitlab-ce/issues/3678 is something that are needed for really large organizations and for people hosting on GitLab.com, so in my view it can be EE only.

For all of the above I try to keep an open mind, so feel free to push back. Based on discussions here we do decide to merge features into CE, for example the branded homepage https://news.ycombinator.com/item?id=10931690


First off, I would really like to commend you for caring and responding to everyone on here. You deserve a lot of kudos for this!

'Test the merge' is something that we already get from GitHub. Travis CI tests both the merge and the branch itself. I think it only makes sense to test both, in fact, if I were to choose one way for a Merge Request, I would just test the merge result.

We have IoT Platform SDKs (See https://github.com/IOT-DSA/sdk-dslink-dart and https://github.com/IOT-DSA/sdk-dslink-java for examples) that at somepoint I would like to pitch the idea to move from GitHub to GitLab fully. We currently utilize GitLab for only a portion of our projects. We find it really helpful that Travis CI tests both the merge result and the branch, and even though I could look over it to switch GitLab (because let's face it, GitLab > GitHub), I would love to be able to tell the other developers that they will only be gaining functionality.

As for the code analytics, I have second guessed myself, and I completely agree with you now. This is definitely something that I see most useful in the enterprise setting.


Thanks for your kind words. I was not aware that Travis CI tests both the branch and the merge, do you maybe have a link to the documentation for this?

There are a couple of ways to implement this feature and we're discussing them in https://gitlab.com/gitlab-org/gitlab-ce/issues/4176 Feel free to join the conversation and/or contribute it. For now this feature is planned for 8.7 but this might change.



> Regarding the 'test the merge' functionality I've only heard requests from large organizations for that, can you detail the context in which you want to use it?

There might be some confirmation bias here going on. In my experience, a lot of enterprise clients I've worked with are using Gitlab. I'm yet to see one major open source project on Gitlab, apart from gitlab itself.


We also have a lot of smaller organization using GitLab on-premises. There are currently few open source projects on GitLab.com, notable ones include Mailman and F-droid.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: