Long time GitLab user here. I'm not sure how I feel about the possibility of GitLab shipping with a persistent chat application. On one hand, much of GitLab is about collaboration, and there are many interesting integration points between the two products. On the other, I prefer the ecosystem of choice per product. I assume that RocketChat could be disabled, or perhaps there would be the option of getting RocketChat and non-RocketChat omnibus installers. Enabling RocketChat on the same server for a large number of users would have hardware implications, and then you're going to through MongoDB in there two (which RocketChat uses). It just feels like too much going on in one system.
I believe Mattermost is disabled by default and supports the option of running on a separate server, so that will hopefully be how RocketChat is integrated as well!
Indeed, RocketChat will be disabled by default as well. It will have a different url (FQDN) so you can run it on a separate server if you want to. We will only ship Rocket Chat if it uses PostgreSQL instead of MongoDB as noted in release announcement.
GitLab seems to be on fire in terms of product development. I'm truly inspired by the "transparent by default" business policies and commitment to openness.
Since I'm interested in highly concurrent web services I thought it was interesting they are underway porting their http server from Ruby's Unicorn to Golang. It would be nice to see a separate post on this process and any performance comparisons.
Checking out the source code[1] I noticed how nice and full featured the GitLab UI. As a daily GitHub user I was pleasantly surprised by how comfortable I was navigating around.
Thanks for all your kind words. Glad to hear you appreciate our openness and that our UI was easy to navigate. We're still working on performance testing the new http server. I'll ask Jacob to consider writing a blog post when he is done.
> It would be nice to see a separate post on this process and any performance comparisons.
We (I) see gitlab-git-http-server more as a functional improvement than as a performance improvement. It is a better match for slow Git HTTP requests ('git push', 'git pull') than Unicorn+Rails.
Having said that, I am also curious about what this change means for performance and other areas. It already helped us find a performance issue in the Rails app.
It seems like gitlab changes syntax highlighters a lot.
I keep hoping for the really nice syntax highlighting features, like doing diff highlighting and the actual filetype highlighting at the same time. Or highlighting SQL inside a string as SQL.
12 comments
[ 4.8 ms ] story [ 46.0 ms ] threadSince I'm interested in highly concurrent web services I thought it was interesting they are underway porting their http server from Ruby's Unicorn to Golang. It would be nice to see a separate post on this process and any performance comparisons.
Checking out the source code[1] I noticed how nice and full featured the GitLab UI. As a daily GitHub user I was pleasantly surprised by how comfortable I was navigating around.
[1] https://gitlab.com/gitlab-org/gitlab-git-http-server
We (I) see gitlab-git-http-server more as a functional improvement than as a performance improvement. It is a better match for slow Git HTTP requests ('git push', 'git pull') than Unicorn+Rails.
Having said that, I am also curious about what this change means for performance and other areas. It already helped us find a performance issue in the Rails app.
https://gitlab.com/gitlab-org/gitlab-ce/issues/2341
I keep hoping for the really nice syntax highlighting features, like doing diff highlighting and the actual filetype highlighting at the same time. Or highlighting SQL inside a string as SQL.