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.
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.
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.
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.
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.
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
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.
We currently use docker-compose for the development environment. I'm currently simplifying this to allow developers to get started with minimal effort:
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.
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."
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 :)
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.
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.
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.
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/
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.
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 michael@neo4j.com.
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.
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 :)
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.
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
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.
reply