Gitter is open source(gitlab.com)
gitlab.com
Gitter is open source
https://gitlab.com/gitlab-org/gitter/webapp/
175 comments
The biggest problem I have with something like this is that unlike SO the answers aren't archived for others who may have the same issue. It would be nice if discussions like this on Gitter could be archived and searched the way mailing lists are.
All public rooms are archived and searchable:
https://gitter.im/gitterHQ/gitter/archives/all https://gitter.im/gitterHQ/gitter/archives/2017/06/14
I agree that chat isn't as digestible as SO, but it is definitely archived.
https://gitter.im/gitterHQ/gitter/archives/all https://gitter.im/gitterHQ/gitter/archives/2017/06/14
I agree that chat isn't as digestible as SO, but it is definitely archived.
Right, I meant more in a Q&A fashion with perpendicular discussion like with SA. But I'm happy to see there is an archive. I've had decade old Mozilla bug reports save me more than once.
Thank you :)
Gitter is a great idea in theory. In practice it's just been a place for my questions to go unanswered.
Personally, I don't think that it's even a right format for questions which are not part of a larger discussion (e.g. deciding on details of some issue or PR).
I have never seen link to gitter in google search results, and answers vanishing forever (not sure how good gitter search is though) does not sound good. Once I joined a few channels because I wanted to ask maintainers a quick question if $xyz sounds feasible or am I strongly misunderstanding things, because had some ideas how I could contribute. These were rather popular repos and all channels were full of low effort questions that could be either google-able or answered by spending a few minutes playing around.
I have never seen link to gitter in google search results, and answers vanishing forever (not sure how good gitter search is though) does not sound good. Once I joined a few channels because I wanted to ask maintainers a quick question if $xyz sounds feasible or am I strongly misunderstanding things, because had some ideas how I could contribute. These were rather popular repos and all channels were full of low effort questions that could be either google-able or answered by spending a few minutes playing around.
I co-maintain an open source project on GitHub that's somewhat popular (>1.5k stars). We set up Gitter because I preferred Slack which my collaborator didn't use, and he preferred Gchat which I didn't use, and Gitter looked like a reasonable middle ground. Since then it's mostly been a communication channel between us two. We do get a user question once in a while, and I do answer when I get a notification email. Basically, for users it's like opening an issue, just less formal.
That doesn't sound like a Gitter issue but a lack of activity in that particular project/community.
Some projects prefer email/github issues over chat as there isn't an active community around it 24/7 for anyone to just jump in and ask away.
I maintain an open source project where we have set up Gitter awhile ago. So far -even with a really small community like ours- I'm answering questions and interacting with users regularly.
Some projects prefer email/github issues over chat as there isn't an active community around it 24/7 for anyone to just jump in and ask away.
I maintain an open source project where we have set up Gitter awhile ago. So far -even with a really small community like ours- I'm answering questions and interacting with users regularly.
Totally not a gitter platform issue, but these platforms aren't really distinguishable from their user communities at the end of the day.
If Facebook only had 2-3 of your friends on it, no one would be impressed by the features and sophistication, they wouldn't get that far.
If Facebook only had 2-3 of your friends on it, no one would be impressed by the features and sophistication, they wouldn't get that far.
https://gitter.im/explore/tags/curated:frontend
There are some channels with thousands of users and high activity.
* VueJS 12,000+
* Webpack ~10,000
* angular.js ~8,500
* boostrap ~6,000
* docker ~4,000
* gulp ~2,500
* eslint ~1,000
* ansible <1,000
There are some channels with thousands of users and high activity.
* VueJS 12,000+
* Webpack ~10,000
* angular.js ~8,500
* boostrap ~6,000
* docker ~4,000
* gulp ~2,500
* eslint ~1,000
* ansible <1,000
That is just not fair to say that gitter is the reason your questions go unanswered. Gitter is a chat technology. It depends on who you're chatting with not the underlying technology. Its like calling and ordering pizza, and then blaming your phone because the pizza is cold.
Gitter has been a huge part of freeCodeCamp's community since the beginning. Thousands of people have asked questions there, and most of them have gotten helpful answers quickly. This is thanks to the experienced developers who contribute their time and expertise in there.
Like IRC, it's a great platform to ask and answer questions on. Find the right rooms and talk to the right people.
Like IRC, it's a great platform to ask and answer questions on. Find the right rooms and talk to the right people.
This reminds me of something I want to share with HN. I've put a lot of thought into how technologists seem to forget to think about how their tools will be adopted and used in a collective sense. They seem to not design their tools for the end result.
https://medium.com/@xpe/designing-effective-communication-67...
> Can your product provide a great user experience for the group sizes and compositions you want to support?
> Can your product maintain the tone and engagement levels you seek?
https://medium.com/@xpe/designing-effective-communication-67...
> Can your product provide a great user experience for the group sizes and compositions you want to support?
> Can your product maintain the tone and engagement levels you seek?
Probably slightly orthogonal to your post, but @aurynn on Twitter has had some thoughts about UX in relation to open source:
https://twitter.com/aurynn/status/882411143611924480
https://twitter.com/aurynn/status/882036680869371904
Confronting, but accurate.
https://twitter.com/aurynn/status/882411143611924480
https://twitter.com/aurynn/status/882036680869371904
Confronting, but accurate.
This sounds like more of a problem of the projects that you are interacting with more so than the platform?
I could say the same thing about many IRC channels, heck, even the internet in general.
I could say the same thing about many IRC channels, heck, even the internet in general.
I've found gitter really good for popular projects, you can ask fuzzy questions that aren't suitable for something like stack overflow.
some gitter communities are pretty dead though.
some gitter communities are pretty dead though.
It depends on the project & maintainers, not the tool. When I was learning webpack a couple years ago I had a great experience asking for help in their gitter.
Used it for a locomotivecms (ruby) question, got it answered in a VERY (happily) surprising manner, and proudly supported its development.
Great tool when used effectively.
Great tool when used effectively.
It may work better integrated directly with Gitlab as they will probably pay close attention to the community development.
While I applaud the initiative of Gitlab to opensource Gitter I think the target audience for self hosting is rather small. I think alternatives like Zulip or Mattermost are probably better suited for most organizations.
I am however interested to see if the community starts making the "main instance" (gitter.im) better.
Interested to know what the Gitlab / Gitter guys and gals think what the target audience is.
I am however interested to see if the community starts making the "main instance" (gitter.im) better.
Interested to know what the Gitlab / Gitter guys and gals think what the target audience is.
Great question.
We're trying to achieve two things with open sourcing Gitter.
Firstly, we see Gitter as more of a community than a product. That we have nearly 1,000,000 developers coming together on the platform to talk about code and open source software where public rooms far, far outweigh private rooms, is testament to that. So we're not trying to compete with MatterMost.
What we're trying to facilitate is to allow the community and users of GitLab to contribute to the experience of the community. We've always had a very small team at Gitter and the surface area of the product is massive. This way the community can help us make it a better place by improving the product.
We also have some communities who are interested in running their own public instance entirely. Sure they could use other products, but Gitter is built community and public first and suits a lot of different needs that other products don't necessarily facilitate out of the box.
We're trying to achieve two things with open sourcing Gitter.
Firstly, we see Gitter as more of a community than a product. That we have nearly 1,000,000 developers coming together on the platform to talk about code and open source software where public rooms far, far outweigh private rooms, is testament to that. So we're not trying to compete with MatterMost.
What we're trying to facilitate is to allow the community and users of GitLab to contribute to the experience of the community. We've always had a very small team at Gitter and the surface area of the product is massive. This way the community can help us make it a better place by improving the product.
We also have some communities who are interested in running their own public instance entirely. Sure they could use other products, but Gitter is built community and public first and suits a lot of different needs that other products don't necessarily facilitate out of the box.
I agree that self-hosting audience is probably small for this, but open sourcing also changes its image and workflow a bit.
I'd much rather pay for a hosted FLOSS app, than a hosted closed source app (assuming similar capabilities). Being able to inspect the code, and knowing that anyone's free to collaborate or reuse the code really makes a difference on where I choose to put my money.
I'd much rather pay for a hosted FLOSS app, than a hosted closed source app (assuming similar capabilities). Being able to inspect the code, and knowing that anyone's free to collaborate or reuse the code really makes a difference on where I choose to put my money.
They are creating the infrastructure for some kind of projects that currently don't exist. Local / national Githubs/software communities might be a thing soon, and Gitlab will be powering it if happens.
Self-hosting market isn't that small. The entire gov/aerospace/anything with ITAR/ETAR etc is stuck with very few options that are self-hosted or fedramp approved cloud options.
Maybe something like GNU social. They already use Gitlab CE for the repos. Add gitter and we have replaced IRC.
You say that as if it's a good thing...
IRC is not going anywhere but projects like neovim use gitter primarily while IRC is linked using a bot. They view the IRC chat in gitter.
Dunno if Gitter is better than IRC as I have only used for help and support (for me) but Gitter was far easier to use than IRC. Just Login and start chatting.
I don't think IRC is going anywhere either... We just have alternatives to freenode now in Gitter
Dunno if Gitter is better than IRC as I have only used for help and support (for me) but Gitter was far easier to use than IRC. Just Login and start chatting.
I don't think IRC is going anywhere either... We just have alternatives to freenode now in Gitter
> IRC is not going anywhere
I don't know if this still holds true. I've been a IRC user for ~20 years and the current state is a fraction of the fraction of it was once before. Compared with the entire internet, it can already be considered irrelevant, imo.
I don't know if this still holds true. I've been a IRC user for ~20 years and the current state is a fraction of the fraction of it was once before. Compared with the entire internet, it can already be considered irrelevant, imo.
IRC as general chatting service is outdated. IRC as communication between developers and for tech support is relevant because it's easier and simpler to set up and use.
Gitter has had an IRC bridge since pretty much day 1. This allows you to connect to Gitter via any IRC client.
https://irc.gitter.im
https://irc.gitter.im
it's not very comfortable to use though. Partially because the gitter features don't match how IRC is used 1:1, partially because it seems to have some bugs and sometimes does the simplest possible but uncomfortable thing (which might now get fixed!)
Apropos, does anyone know of a hosting provider with one-click installs of Weechat? It would be nice to have something slightly more self-hosted than irccloud to recommend to the GsoC/GCI students who keep disconnecting from freenode :)
(You'd think with all the Wordpress one-click-installs that this would exists, but I can't find any yet at least.)
(You'd think with all the Wordpress one-click-installs that this would exists, but I can't find any yet at least.)
I'd suggest using Riot.
See https://opensource.com/article/17/5/introducing-riot-IRC, https://about.riot.im/ and https://matrix.org/.
See https://opensource.com/article/17/5/introducing-riot-IRC, https://about.riot.im/ and https://matrix.org/.
Actually, there is. There’s a sandstorm config for Quassel, with webinterface, quassel bouncer, etc included.
I’m not sure if quassel-irssi is also included, but that and quassel-rest-search should be easy to add.
I’m not sure if quassel-irssi is also included, but that and quassel-rest-search should be easy to add.
Does Gitter have federated servers using a standard protocol and a vast array of programmable extensions? None of these hosted solutions are even in the same league as IRC, and we are worse off for it.
As someone who has written an IRC server implementation, there is no standard protocol. There is an RFC, but no one implements it. Instead, each server uses its own mix of poorly documented pseudo-standards.
Asking users to run mongo, es, neo4j, and redis is a tall order. Mattermost just needs (AFAIK) a relational database.
Also, less relevant but the Gitlab UI has far too much wasted whitespace. Like 85% of the page is navigation. I like open source competitors to incumbents but maybe just copy Github here - no one is gonna say anything.
Also, less relevant but the Gitlab UI has far too much wasted whitespace. Like 85% of the page is navigation. I like open source competitors to incumbents but maybe just copy Github here - no one is gonna say anything.
Hi, co-founder of Gitter here.
Gitter is not intended to be a replacement for Mattermost, Slack or other team collaboration tools. We see Gitter as a community instead.
As such, we're not expecting to see a huge uptake of on-site installations, so the list of required services (es, neo etc) is big compared to other products focused on on-prem.
We're hoping that our users will contribute to the main site, Gitter.im.
Obviously, we're also totally happy with users running their own Gitter installations but, while we would like it to be easy, ease-of-installation of a production instance is not a goal currently.
Gitter is not intended to be a replacement for Mattermost, Slack or other team collaboration tools. We see Gitter as a community instead.
As such, we're not expecting to see a huge uptake of on-site installations, so the list of required services (es, neo etc) is big compared to other products focused on on-prem.
We're hoping that our users will contribute to the main site, Gitter.im.
Obviously, we're also totally happy with users running their own Gitter installations but, while we would like it to be easy, ease-of-installation of a production instance is not a goal currently.
What would be the hardware requirements to run gitter for a couple of hundred accounts?
We haven't done much benchmarking at that end of the scale, but I can't think of any reason why you wouldn't be able to run it on a single server.
Sure, but is it a 5USD/month DO instance or a 640USD/month one?
The easiest route for installations would be to offer a docker image and docker-compose file to set up the multiple services.
We currently use docker-compose for the development environment. I'm currently simplifying this to allow developers to get started with minimal effort:
https://gitlab.com/gitlab-org/gitter/webapp/blob/feature/mon...
Going forward, I agree that we could offer a more production-like docker-compose setup and/or Kubernetes Helm Charts.
https://gitlab.com/gitlab-org/gitter/webapp/blob/feature/mon...
Going forward, I agree that we could offer a more production-like docker-compose setup and/or Kubernetes Helm Charts.
> we would like it to be easy, ease-of-installation of a production instance is not a goal currently.
ok but doesn't it behoove you anyway to have e.g. dockerfile and/or ansible roles for dev/staging environments?
ok but doesn't it behoove you anyway to have e.g. dockerfile and/or ansible roles for dev/staging environments?
They probably do have some sort of automation, but it's likely specific to their environment.
We use Ansible / packer & terraform. Open sourcing this repo will be fairly complicated but it may make more sense for us to publish a k8s helm chart or more complete, production-ready docker-compose.yml
you are already using docker-compose.yml. you should use definitely do a production ready docker swarm deployment. you only will need to do incremental changes to your docker-compose
Make a merge request.
We have a docker-compose.yml for development environments and I'm currently in the process of simplifying this[1] so that Docker for Mac/Windows will be able to spin up an environment with little effort.
We use ansible for provisioning beta/staging and production. We have yet to open source the ansible repository but, since we're switching to GitLab CI/CD, the deployment process will soon be publicly accessible - even for production.
1: https://gitlab.com/gitlab-org/gitter/webapp/merge_requests/1... so that
We use ansible for provisioning beta/staging and production. We have yet to open source the ansible repository but, since we're switching to GitLab CI/CD, the deployment process will soon be publicly accessible - even for production.
1: https://gitlab.com/gitlab-org/gitter/webapp/merge_requests/1... so that
This is actually the first real project I've come across that uses neo4j - thank you for pointing that out.
Given the requirements, I actually think this project looks rather clean between the docker-compose-file and the npm dependencies.
I very much doubt it can compete with Mattermost or Rocket.chat for self-host for small organizations - but I'm really happy to see this thing open sourced!
I much prefer it to be opened up as soon as possible, and then flicked on later.
If there's one thing I'd like to see (beyond a reduction in what appears to be a default of three? mongodb instances) - it would probably be a set of juju charms for bringing the thing up under lxc/lxd on Ubuntu.
I just revisited the combination of juju+ubuntu+lxd - and while I was skeptical when juju was introduced, it appears to be a rather sane toolkit for automating deployment IMNHO.
For those interested, if you start here:
https://insights.ubuntu.com/2016/06/08/lxd-2-0-lxd-and-juju/
you might think that this thing is insane overkill - but if you start at the beginning of the series[s], you will (or I did) get a warm fuzzy feeling about how much fun it is to play with lxd on top of zfs. I suppose some people think docker is just as fun (and warm and fuzzy) - but I don't know. LXD does feel like it combines the good parts of linux with the good parts of bsd jails.
[s] https://insights.ubuntu.com/2016/03/14/the-lxd-2-0-story-pro...
Given the requirements, I actually think this project looks rather clean between the docker-compose-file and the npm dependencies.
I very much doubt it can compete with Mattermost or Rocket.chat for self-host for small organizations - but I'm really happy to see this thing open sourced!
I much prefer it to be opened up as soon as possible, and then flicked on later.
If there's one thing I'd like to see (beyond a reduction in what appears to be a default of three? mongodb instances) - it would probably be a set of juju charms for bringing the thing up under lxc/lxd on Ubuntu.
I just revisited the combination of juju+ubuntu+lxd - and while I was skeptical when juju was introduced, it appears to be a rather sane toolkit for automating deployment IMNHO.
For those interested, if you start here:
https://insights.ubuntu.com/2016/06/08/lxd-2-0-lxd-and-juju/
you might think that this thing is insane overkill - but if you start at the beginning of the series[s], you will (or I did) get a warm fuzzy feeling about how much fun it is to play with lxd on top of zfs. I suppose some people think docker is just as fun (and warm and fuzzy) - but I don't know. LXD does feel like it combines the good parts of linux with the good parts of bsd jails.
[s] https://insights.ubuntu.com/2016/03/14/the-lxd-2-0-story-pro...
(Gitter Co-founder here)
Unfortunately our neo4j setup as it stands really doesn't scale. At an application-level we're built error-handling to gracefully handle the frequent outages we experience running it.
These are probably our fault, rather than a failing in the product, but I've wanted to replace the current neo4j-based suggestion algo with a new one that uses batching/clustering for a while. As soon as I get a chance, I would like to remove the dependency we have on neo4j.
Unfortunately our neo4j setup as it stands really doesn't scale. At an application-level we're built error-handling to gracefully handle the frequent outages we experience running it.
These are probably our fault, rather than a failing in the product, but I've wanted to replace the current neo4j-based suggestion algo with a new one that uses batching/clustering for a while. As soon as I get a chance, I would like to remove the dependency we have on neo4j.
It looks like you're still using Neo4j 2.3. Have you tried using newer versions of Neo4j? There have been some pretty substantial performance improvements.
Additionally, Neo4j does support clustering with their Enterprise edition. It also has much better tooling (better metrics/logging, backups, etc.). It is AGPL licensed, so there's no reason not to use it really.
Additionally, Neo4j does support clustering with their Enterprise edition. It also has much better tooling (better metrics/logging, backups, etc.). It is AGPL licensed, so there's no reason not to use it really.
you should really look at Janus (with Cassandra as the backing datastore). http://janusgraph.org/
Since it uses Gremlin, you should not have that big a problem in porting.
Since it uses Gremlin, you should not have that big a problem in porting.
You might want to reach out to Al Baker or Kendall Clark at Stardog. Their product is more RDF centric than for generic graphs like Neo4j, but is in my opinion a much better product. They have a community version, and have open sourced several pieces, but it is commercial. https://www.stardog.com/docs/
If you want pure Open Source then Titan might be a good fit for Gitter. http://titan.thinkaurelius.com/
If you want pure Open Source then Titan might be a good fit for Gitter. http://titan.thinkaurelius.com/
The big problem with the way we use neo4j is around huge rooms with ~100K users. The number of possible rooms that neo4j has to traverse (even a shallow traversal) for a user in a big room is huge.
Thanks for your recommendations. I'll definitely check them out.
Thanks for your recommendations. I'll definitely check them out.
Those huge rooms really don't add anything to recommendations (like everyone buys milk), if almost everyone is in the room you can also just leave it off (the same is true for rooms with very few users).
That's why in recommendations, I usually filter them out b degree (which is a constant value read).
MATCH (r:Room) WHERE size( (r)<-[:MEMBER]-() ) < 5000) ...
You're also not using directions in your queries, which will also help.
I looked at your other queries, they can also be improved easily, if you want to I can help you do that. Just need some sample data or a read-only access to the db. Just ping me at [email protected].
That's why in recommendations, I usually filter them out b degree (which is a constant value read).
MATCH (r:Room) WHERE size( (r)<-[:MEMBER]-() ) < 5000) ...
You're also not using directions in your queries, which will also help.
I looked at your other queries, they can also be improved easily, if you want to I can help you do that. Just need some sample data or a read-only access to the db. Just ping me at [email protected].
Why not get in touch with us and let us help you instead of dropping us?
I'm totally open to that.
I'm not going to be changing anything around the suggestions any time soon, but who should I get in touch with when I do?
I'm not going to be changing anything around the suggestions any time soon, but who should I get in touch with when I do?
Email me: [email protected]
> Also, less relevant but the Gitlab UI has far too much wasted whitespace.
And why do I always need to scroll down to see the project README?
And why do I always need to scroll down to see the project README?
There is a small hack on Gitlab for that actually: right under the textbox with the clone URI there is a link to the README.
Files (209 MB) / Commits (44,194) / ... / Readme / MIT License / Contribution guide / ...
Files (209 MB) / Commits (44,194) / ... / Readme / MIT License / Contribution guide / ...
You mean exactly like with Github?
Solution: https://gitlab.com/gitlab-org/gitter/webapp/blob/master/READ...
Solution: https://gitlab.com/gitlab-org/gitter/webapp/blob/master/READ...
But now I'm having problems with the length of the URL :)
PS: yes, same problem with github
PS: yes, same problem with github
> Asking users to run mongo, es, neo4j, and redis is a tall order.
Not really. Why? Reddit is opensource but it'd damn hard to setup correctly and start your own instance.
Not really. Why? Reddit is opensource but it'd damn hard to setup correctly and start your own instance.
Just because Reddit does it rather badly does not mean that other OSS projects shouldn't try to do better.
>Just because Reddit does it rather badly
What about other OSS project? It's also not easy to make Linux from scratch. Being OSS doesn't mean it will be single click to run your instance.
What about other OSS project? It's also not easy to make Linux from scratch. Being OSS doesn't mean it will be single click to run your instance.
Linux doesn't really have to since 99% of users use distributions, not LFS.
And there's a difference between gratuitous (or almost gratuitous) dependencies and must have ones. From what I read in the other comments Neo4J doesn't feel like a must-have for this project.
Plus, to be honest, Mongo, Neo4J, Redis AND Elastic Search? That's got to be overkill :)
And there's a difference between gratuitous (or almost gratuitous) dependencies and must have ones. From what I read in the other comments Neo4J doesn't feel like a must-have for this project.
Plus, to be honest, Mongo, Neo4J, Redis AND Elastic Search? That's got to be overkill :)
The reddit repo doesn't have any commits since March. If that's their actual codebase, what are all their engineers doing?
It's not the actual codebase, it's kind of a branch that has to be manually updated (by cherry-picking across commits from the "real" one). It used to be kept in pretty close sync with the code live on the site, but it seems like they don't care about updating it any more. There are things that have been live on the site for close to a year now that aren't in the open-source repo.
That's roughly what I had guessed. Thanks for clarifying.
Hiya,
Sorry to hear you're displeased with our UI. We'd love to hear any suggestions you might have. We're always looking to improve as much as we can. You can open an issue in https://gitlab.com/gitlab-org/gitlab-ce/issues
Sorry to hear you're displeased with our UI. We'd love to hear any suggestions you might have. We're always looking to improve as much as we can. You can open an issue in https://gitlab.com/gitlab-org/gitlab-ce/issues
Matrix is also quite good on this. Homeserver and PSQL (and maybe nginx), done.
Gitlab UI is the worst. I hope they do less features and just fix their god-awful UI for once!
Hiya,
Sorry to hear that you're displeased with our UI. We'd love to hear any specific feedback you might have. You can also open an issue in https://gitlab.com/gitlab-org/gitlab-ce/issues
We're always looking to improve
Sorry to hear that you're displeased with our UI. We'd love to hear any specific feedback you might have. You can also open an issue in https://gitlab.com/gitlab-org/gitlab-ce/issues
We're always looking to improve
Interesting (and rude). I think it's much better than any other group chat app. Especially for groups organised around code projects.
I was talking about GitLab, not Gitter.
Yes it's rude, but I want to love GitLab - it's amazing. However I just can't bring myself over with this UI. It's just too bad and too unintuitive. Also slow.
Yes it's rude, but I want to love GitLab - it's amazing. However I just can't bring myself over with this UI. It's just too bad and too unintuitive. Also slow.
Oh, sorry I missed that you said GitLab. It's less rude if you're not commenting on the open sourcing of a project to just say negative stuff about it :)
I have to use GitLab for work and I find the UI much harder to use than GitHub, so I agree there. But, it's open source and we can all contribute, and in particular the best place to make your feelings know about the UI is constructively in the issue tracker.
Here's the main issue sparked from the last HN discussion about GitLab UI: https://gitlab.com/gitlab-org/gitlab-ce/issues/25752
I have to use GitLab for work and I find the UI much harder to use than GitHub, so I agree there. But, it's open source and we can all contribute, and in particular the best place to make your feelings know about the UI is constructively in the issue tracker.
Here's the main issue sparked from the last HN discussion about GitLab UI: https://gitlab.com/gitlab-org/gitlab-ce/issues/25752
From my own experience, Gitlab is fast for as long as u have sufficient RAM available. It becomes slow when the SWAP is hitted.
This type of feedback is almost completely useless for a project. "the worst", "too bad", and "unintuitive" are not actionable so if you really want to help a project then describe concrete issues.
I'm not an UI/UX expert but a back-end developer. I cannot give you more feedback then this.
"I'm not an UI/UX expert but a back-end developer."
This actually makes you the perfect candidate for giving us good feedback. You may not be able to articulate exactly why UI elements feel off or don't work for you, but you know they could be better. If you are interested, you can join our UX Research Panel to help us pinpoint areas we can improve. We want you to love GitLab too :)
https://about.gitlab.com/researchpanel/
This actually makes you the perfect candidate for giving us good feedback. You may not be able to articulate exactly why UI elements feel off or don't work for you, but you know they could be better. If you are interested, you can join our UX Research Panel to help us pinpoint areas we can improve. We want you to love GitLab too :)
https://about.gitlab.com/researchpanel/
> Also slow.
Only on gitlab.com, on prem here it flies.
Only on gitlab.com, on prem here it flies.
Same here. Extremely fast on a 4GB VM.
A relational database is overkill. My BBCode-enabled chatroom runs off txt files.
Mattermost isn't exactly a simple bbcode-enabled chatroom though. They have support for multiple projects, an API etc. Achieving this with just text files would be quite the headache.
They also have horrible android client and you have to pay for mobile notifications.
I ended up using matrix/riot instead. Much better clients and grows nicely.
I ended up using matrix/riot instead. Much better clients and grows nicely.
Hi omnimus, thanks for the mention.
Mattermost has a brand new, open source Android client in beta written in React Native used by thousands of testers: https://play.google.com/store/apps/details?id=com.mattermost...
It's greatly improved from the original version and official release is this month.
Mattermost mobile notifications aren't a commercial feature, they are just off by default due to privacy (push notifications appear on a mobile device when the device is locked).
Go to System Console > Notifications > Mobile Push > Send Push Notifications to enable.
You can also deploy your own Mattermost Push Notification Server (https://github.com/mattermost/mattermost-push-proxy) and compile your own Mattermost Android and iOS apps (https://github.com/mattermost/mattermost-mobile) for total control.
Mattermost has a brand new, open source Android client in beta written in React Native used by thousands of testers: https://play.google.com/store/apps/details?id=com.mattermost...
It's greatly improved from the original version and official release is this month.
Mattermost mobile notifications aren't a commercial feature, they are just off by default due to privacy (push notifications appear on a mobile device when the device is locked).
Go to System Console > Notifications > Mobile Push > Send Push Notifications to enable.
You can also deploy your own Mattermost Push Notification Server (https://github.com/mattermost/mattermost-push-proxy) and compile your own Mattermost Android and iOS apps (https://github.com/mattermost/mattermost-mobile) for total control.
Sadly the Android's react version seems to lack any share features - the app doesn't appear in any 'share to' dialogues, nor can I share pictures or such from the app itself (For example using rocket.chat I can long press on an image and I will be able to share the picture to other apps). The issue appears to only have around 100 combined votes on uservoice (https://mattermost.uservoice.com/forums/306457-general/sugge... + https://mattermost.uservoice.com/forums/306457-general/sugge...) so I'm not holding my breath for this to be implemented anytime soon, but it would be a really useful feature to have for when you need to move graphical assets around and you want to take a quick look on your phone for example.
> Asking users to run mongo, es, neo4j, and redis is a tall order
They do provide a docker-compose.yml, which you can use in Docker Swarm, ECS, etc to stand up the entire stack.
They do provide a docker-compose.yml, which you can use in Docker Swarm, ECS, etc to stand up the entire stack.
As an aside, I badly miss the Github language statistics in gitlab repositories. This is one of the crucial info for any developer browsing through new repos and it is very counter-intuitive to have this info hidden from homepage.
See https://gitlab.com/gitlab-org/gitter/webapp/graphs/master/ch...
I agree it's not very prominent. (GitLab Inc. developer)
I agree it's not very prominent. (GitLab Inc. developer)
Would it be possible to use a bar chart instead. Pie charts are kind of a pain.
In addition to that, I'd like to see the number of SLOC for each language to get an idea how large the project is. Is this a weekend project? Is this Linux kernel?
With `npm` and the current JavaScript culture, both a weekend project and the Linux kernel could have the same number of SLOC.
If people check in their node_modules, that's a good sign to stay away from the project.
What? Why? Why shouldn't I be able to run my entire application without relying on 3rd party distribution channels? Caching my dependencies in node_modules is perfectly reasonable to me. It's not like I'm getting binary diffs. It's Javascript.
You're not caching anything by checking it in git, you're mirroring it (very poorly). Your filesystem caches it; you still rely on your remote to download it.
If you want to mirror your dependencies, run an npm mirror subset or something. If that sounds crazy to you, that's because mirroring npm dependencies is unnecessary for virtually everybody.
Oh, and you are also making your .git folder 100x larger than it otherwise would be, making your initial download and on-disk sizes a lot bigger, which can also slow down other git operations. Not to mention the atrocious amount of noise whenever someone does a git blame, git log, git log -S, ...
In other words, checking in your entire dependency source tree in git is unnecessary, wasteful and annoying in the best case scenario.
If you want to mirror your dependencies, run an npm mirror subset or something. If that sounds crazy to you, that's because mirroring npm dependencies is unnecessary for virtually everybody.
Oh, and you are also making your .git folder 100x larger than it otherwise would be, making your initial download and on-disk sizes a lot bigger, which can also slow down other git operations. Not to mention the atrocious amount of noise whenever someone does a git blame, git log, git log -S, ...
In other words, checking in your entire dependency source tree in git is unnecessary, wasteful and annoying in the best case scenario.
Caching node_modules is fine, but not in the mainline branches of your source control. Let your CI system put it somewhere, after it passed tests. Tarball, a dedicated git repo/branch, Docker image or whatever else is practical.
To control versions of dependencies pull in, narrow your specifiers in package.json, verify that the deps use semver sanely, and consider a lockfile.
https://docs.npmjs.com/files/package-locks
> Why shouldn't I be able to run my entire application without relying on 3rd party distribution channels?
You should. That does not mean you should host source code and build output together.
> Caching my dependencies in node_modules is perfectly reasonable to me.
Precisely. That's caching. Not source hosting.
> It's not like I'm getting binary diffs. It's Javascript.
Binary node modules aren't uncommon, BTW.
----
Of course, you could be using git for more than source hosting, and I think that's precisely what your parent was commenting about.
You should. That does not mean you should host source code and build output together.
> Caching my dependencies in node_modules is perfectly reasonable to me.
Precisely. That's caching. Not source hosting.
> It's not like I'm getting binary diffs. It's Javascript.
Binary node modules aren't uncommon, BTW.
----
Of course, you could be using git for more than source hosting, and I think that's precisely what your parent was commenting about.
Page should tell at first glance what gitter DOES.
Great point. We "soft launched" this yesterday so are still working on the documentation and hadn't made any official announcement yet until we've ironed out in any kinks.
Looks like HN announced it for us...
Looks like HN announced it for us...
Blame reddit rather, that's where I saw it and only then posted here. https://www.reddit.com/r/programming/comments/6l2jjj/gitter_...
s/blame/thank/g
...and please turn off that heads on world animation thing. It's annoying and distracting.
Just leave them on. We get the message.
Just leave them on. We get the message.
Yes they should have at least added the website url which is btw. http://gitter.im
Thanks for pointing this out.
I opened an issue about having a description of the project in the landing page: https://gitlab.com/gitlab-org/gitter/webapp/issues/1746
There's also https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 which always shows you where you are (within GitLab), which is tangentially related
I opened an issue about having a description of the project in the landing page: https://gitlab.com/gitlab-org/gitter/webapp/issues/1746
There's also https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 which always shows you where you are (within GitLab), which is tangentially related
Gitter[1] is a chat service integrated with Github. They was acquired by Gitlab a few months ago
[1] http://gitter.im/We've edited the description of the project now that has a simple explanation and a link to Gitter. Thanks for the feedback, keep it coming!
[deleted]
I was slightly annoyed by this too (that it lacks this simple info)
If you go through the commit history you can see that they removed a lot of secret keys from the repo.
What if the main reason why people don't want to opensource their project is because they don't know how to use their secret keys without including them in the repo ?
What if the main reason why people don't want to opensource their project is because they don't know how to use their secret keys without including them in the repo ?
Andrew, co-founder of Gitter here.
Removing secrets was a lot of work - more than I expected - while we open-sourced the product.
I agree with your sentiment though. Handling secrets in a codebase is not something that it currently easy or standardised.
As an aside, BFG Repo Cleaner really helped a lot with cleaning things up: https://rtyley.github.io/bfg-repo-cleaner/
Removing secrets was a lot of work - more than I expected - while we open-sourced the product.
I agree with your sentiment though. Handling secrets in a codebase is not something that it currently easy or standardised.
As an aside, BFG Repo Cleaner really helped a lot with cleaning things up: https://rtyley.github.io/bfg-repo-cleaner/
It's been my impression that the standard (promoted by services like Heroku and Travis) is to pass secrets as environment variables.
Fair enough: this is exactly what we've moved to on Gitter on Gitter since open-sourcing the product.
I quite like git-crypt for secrets, I store them in a single place (eg as environment variables) and encrypt that.
Not having started out as an open source project, this was always a major consideration.
Once we've finished fully open sourcing everything, we should look to write up our experience around the conversation, in particular, the tools we used.
Once we've finished fully open sourcing everything, we should look to write up our experience around the conversation, in particular, the tools we used.
ENVs in a private repo would definitely be convenient, but the best practices I've always seen are to omit those values even from a private repo (for security but also portability)
I just wish I had time to work in my side-project http://git.chat and investigate the ability to implement chat-like functionalities into the git-repo/protocol itself.
I really think any kind of discussions related to open-sourced projects should be stored together with it rather than a 3rd party in a closed environment.
I really think any kind of discussions related to open-sourced projects should be stored together with it rather than a 3rd party in a closed environment.
Start small: a CLI chat client, no auth (auth is the ability to push to the remote), install a fetch hook to notify user of unread chat msgs, done.
At that point anyone can use it.
> Whilst drinking your tea, make sure you have Gulp installed. You can do this with npm install -g gulp. You may need to use sudo for this.
How blind can you be not to understand how evil this request is to your users? And you request this because... because you don't want to `sed 's|gulp |node_modules/.bin/gulp|g' Makefile` ?
Similarly, too hard to check npm's version in Makefile, and run or not run `linklocal` yourselves?
How blind can you be not to understand how evil this request is to your users? And you request this because... because you don't want to `sed 's|gulp |node_modules/.bin/gulp|g' Makefile` ?
Similarly, too hard to check npm's version in Makefile, and run or not run `linklocal` yourselves?
Would you mind elaborating? As a user who would follow this instruction without thinking twice I'd like to understand better why this is a bad idea.
Two others touched on the sudo part but the global flag is as bad. So they have a gulp file that works with gulp "v1". Gitter goes bust (inactive), next year gulp is bumped to "v2", you want to try out gitter, gulp fails, you have to digg why. Another scenario is when another project asks you do the same, install gulp globally, but it actually means gulp "v0". Now you can't run to projects side by side.
Global deps should be versioned, the same way you do not see a respectable npm module with "*" semver in its package.json.
Seeing things like this in 2017 from smth like gitter! now owned by gitlab! is just a big red warning "amateur work, please look away".
How can you have a Makefile, a Makefile! and still require gulp, and still require people to run "npm install"? How? Where's the bare minimum logic?
Global deps should be versioned, the same way you do not see a respectable npm module with "*" semver in its package.json.
Seeing things like this in 2017 from smth like gitter! now owned by gitlab! is just a big red warning "amateur work, please look away".
How can you have a Makefile, a Makefile! and still require gulp, and still require people to run "npm install"? How? Where's the bare minimum logic?
As Gitter was originally built as closed source with a team of people working exclusively on Gitter, this has never really been a problem for us.
This is very much v1 of the setup/instructions and would be delighted to improve them with any MRs or contributions. We'll certainly improve them ourselves over time as we get more people in less controlled environments adopting the project.
This is very much v1 of the setup/instructions and would be delighted to improve them with any MRs or contributions. We'll certainly improve them ourselves over time as we get more people in less controlled environments adopting the project.
Running any npm module install script through sudo is a bad idea unless you are very sure of exactly what will be installed and how. There's a reason why distribution packages are generally signed and package managers require packages match repo sigs.
It's not really that bad, unless you install it with sudo. The need to have gulp installed globally is unnecessary. They could just add it as a normal dependency and put the specific gulp command in the scripts section of their package.json. It wouldn't require the user to do anything extra.
Huh, they seem to be using Marionette for most of the UI apart from using React for "topics UI"
We started Gitter before React was A Thing and Marionette had a lot of the functionality we needed. We even hacked it to do server-side pre-rending and live collection binding. Topics was an experiment in how we could look to move towards react and evaluate blending technologies.
Will the Android app be open sourced as well?
Btw on my phone the notifications are never cleared, always showing a super old message from hundreds of days ago for me. It's annoying because I cannot see why I got the notification. I wonder if this is already in your bug tracker.
Btw on my phone the notifications are never cleared, always showing a super old message from hundreds of days ago for me. It's annoying because I cannot see why I got the notification. I wonder if this is already in your bug tracker.
In the original blog post announcing the Gitlab acquisition (http://blog.gitter.im/2017/03/15/gitter-gitlab-acquisition/), there's mention of open sourcing the mobile apps -- "Next piece of wow: we will be open sourcing all of the Gitter. That’s right, the web application, the mobile apps, the whole nine yards, free and open."
Hey, what do you use neo4j for? I am interested in your use case as I have recently started using it also.
Thanks!
Thanks!
Gitter co-founder here: we use neo4j for suggesting rooms.
So, if you're in room A and room B, and most people in those two rooms are also in room C, then we suggest that you join room C.
As I mentioned elsewhere, we also use some non-neo4j based methods for suggestions (including your GitHub graph). One of the problems we've had with neo4j is that we haven't been able to make it scale. It frequently burns up from being overloaded.
This is almost certainly down to the way we use neo4j but at some point I'd like to ditch it for a clustered suggestion algo that uses batch processes to cluster rooms together.
So, if you're in room A and room B, and most people in those two rooms are also in room C, then we suggest that you join room C.
As I mentioned elsewhere, we also use some non-neo4j based methods for suggestions (including your GitHub graph). One of the problems we've had with neo4j is that we haven't been able to make it scale. It frequently burns up from being overloaded.
This is almost certainly down to the way we use neo4j but at some point I'd like to ditch it for a clustered suggestion algo that uses batch processes to cluster rooms together.
Sounds like you're going to be doing a lot of writes, which neo4j isn't designed for. While I get why you're using it, I'd suggest that it's not really the right tool for that job, which is possibly why you're having problems with it.
Do you really need persistance at all? If the application crashes everyone would be kicked out of the channels anyway no? I think making an in memory graph and ditching the graph DB entirely would be more helpful for that kind of suggestion tool.
Do you really need persistance at all? If the application crashes everyone would be kicked out of the channels anyway no? I think making an in memory graph and ditching the graph DB entirely would be more helpful for that kind of suggestion tool.
We update on a batch[1] fairly infrequently (daily iirc). We don't need exact room membership since the results are aggregated.
> If the application crashes everyone would be kicked out of the channels anyway no
No, Gitter's room membership is persistent (between restarts, crashes and sessions)
1: https://gitlab.com/gitlab-org/gitter/webapp/blob/master/scri...
> If the application crashes everyone would be kicked out of the channels anyway no
No, Gitter's room membership is persistent (between restarts, crashes and sessions)
1: https://gitlab.com/gitlab-org/gitter/webapp/blob/master/scri...
Neo4j Powers a 1.2 Terabytes Size Data with Nearly Three Billion Nodes and Nine Billion Relationships to Create the World’s Largest Consumer Identity Graph. Neo4j’s native graph clustering architecture is ideally suited to deliver real-time query performance at scale, across massive customer graphs. Please see: https://neo4j.com/news/qualia-media-customers-experience-gre...
I hope they'd finally make the search usable. Searching for things in Gitter godawful.
I absolutely LOVE gitter and am floored and enthralled to hear this news. Congrats team!
Glad to hear and thank you very much!
Gitlab UI is truly horrid compared to Github. When I go to a repository page on Gitlab, the navigation and whitespace takes around 80% of my screen. On Github I can immediately see the directory structure.
Also the colour scheme is bad IMO, everything is a light shade of grey, hard to quickly navigate the page as things look all the same while scrolling. Try using some darker shades and more contrast to make different parts of the page more easily distinguished.
Also the colour scheme is bad IMO, everything is a light shade of grey, hard to quickly navigate the page as things look all the same while scrolling. Try using some darker shades and more contrast to make different parts of the page more easily distinguished.
Hiya,
Anything specific about the UI you'd suggest changing? We'd love to hear your feedback so we can improve. Feel free to suggest improvements in https://gitlab.com/gitlab-org/gitlab-ce/issues
Anything specific about the UI you'd suggest changing? We'd love to hear your feedback so we can improve. Feel free to suggest improvements in https://gitlab.com/gitlab-org/gitlab-ce/issues
I agree with commenter. My particular problems (not all about UI).
- Submenu is so gray its hardly visible (the one showing files, commits etc)
- Pipeline interface is horrible. If job is manual it cant be executed from the job page or repeated with latest code without resurfing trough menu.
- Project builds can not be deleted in bulk without using API
- Public projest are basically hidden, I have to explain to everybody how to find something.
- Snippets do not have comments if not part of project.
- Code review not possible outside of commit.
- Submenu is so gray its hardly visible (the one showing files, commits etc)
- Pipeline interface is horrible. If job is manual it cant be executed from the job page or repeated with latest code without resurfing trough menu.
- Project builds can not be deleted in bulk without using API
- Public projest are basically hidden, I have to explain to everybody how to find something.
- Snippets do not have comments if not part of project.
- Code review not possible outside of commit.
Thank you for the specifics, it is helpful to know what UI elements we can improve on.
The submenu is going away. We have done extensive testing on our navigation and are making significant improvements. Take a look at the issue, I would love to know your thoughts:
https://gitlab.com/gitlab-org/gitlab-ce/issues/32794
We have a few issues to address improving the pipelines interface, take a look or create issues with your suggestions on how we can make the UI better for you.
The submenu is going away. We have done extensive testing on our navigation and are making significant improvements. Take a look at the issue, I would love to know your thoughts:
https://gitlab.com/gitlab-org/gitlab-ce/issues/32794
We have a few issues to address improving the pipelines interface, take a look or create issues with your suggestions on how we can make the UI better for you.
I do wonder what your comment has to do with the freaking topic.
I clicked on the title of this post which links to gitlab repository page. And I was frustrated with the UI while trying to find out more about this project.
Clicking on the title brings you to the project page which shows the latest activity for that project. I can understand being frustrated as you most likely expected to land on a page with files and a readme. Clicking on the Repository tab will bring you to this view. Project owners have the option to make the repository view the default view. It looks as though this was not enabled on this project.
Still, the topic is gitter. Please help keep HN noise free and useful by staying on topic.
We're actually completely overhauling the GitLab's UI https://gitlab.com/gitlab-org/gitlab-ce/issues/32794
That looks AMAZING. Maybe even better than GitHub. Great job, can’t wait for this!!!
Gitter is what IRC with fellow developers used to be like. Thanks for recreating that wonderful experience!
Is there any option on GitLab to see instantly in what language a repo is written? (Like GitHub does)
From the project page, choose Repository | Charts.
Beware though, it's pretty slow right now.
It might be quicker to just look at a screenshot of it instead http://imgur.com/a/qBGVf
For reference:
Beware though, it's pretty slow right now.
It might be quicker to just look at a screenshot of it instead http://imgur.com/a/qBGVf
For reference:
JavaScript 86.45 %
CSS 6.79 %
HTML 4.79 %
Shell 1.07 %
Lua 0.82 %
Makefile 0.05 %
Groovy 0.03 %
Python 0.01 %Didn't knew gitlab built gitter.
[deleted]
They didn't build it. They purchased it and announced it would be open sourced a couple of months ago.
Thanks for the news ;)
Hi! GitLab did not built Gitter. It is explained in this blog post: https://about.gitlab.com/2017/03/15/gitter-acquisition/
That'll be helpful.
GitLab, a startup that provides open source and premium source code repository software that people use to collaborate on software, is announcing today that it has acquired Gitter, a startup that provides chat rooms that are attached to repositories of code so that collaborators can exchange messages. Terms of the deal weren’t disclosed.
They announced the acquisition in March¹. Back then they also announced that gitter would be open source so now they released it.
1. https://about.gitlab.com/2017/03/15/gitter-acquisition/
1. https://about.gitlab.com/2017/03/15/gitter-acquisition/
> Gitter requires MongoDB, Redis, ElasticSearch and Neo4J
Why use one database when you can use four!
Why use one database when you can use four!
Do you think they should store account data in redis?
Or maybe they should use the ever-so-performant MongoDB as their cache, that'll work out great.
Actually, scratch that, Gitter should probably store all its relational data in ElasticSearch because why use one database when you can use four?.
Or maybe they should use the ever-so-performant MongoDB as their cache, that'll work out great.
Actually, scratch that, Gitter should probably store all its relational data in ElasticSearch because why use one database when you can use four?.
It has been nice to be able to have a nice way to talk with other open-source collaborators or get quick clarification on a small repo-specific question.
It's cool to see how it was put together.
Thanks for open sourcing this.