suprememoocow

> There is a cookie setting you can use to get some features early on GitLab.com but I can't find a link right now.

Andrew from the Infrastructure team at GitLab here: non-team members are welcome to use our canary service, provided they understand that service may at times we downgraded (they can always switch back to production when this happens).

Details of how to toggle the canary environment can be found in our handbook: https://about.gitlab.com/handbook/engineering/#canary-testin...

Repo tree rendering is a known issue that we're currently looking into: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14680

We hope to make improvements in this area soon. Hopefully you'll notice them!

I'm the Gitaly Lead at GitLab. Gitaly is a GitLab project to move all the git operations out of the GitLab Ruby monolith into a Git RPC service.

https://gitlab.com/gitlab-org/gitaly/

We're hoping to complete this by the end of the year. Once it's done, we'll be able to end our reliance on NFS, which should greatly improve performance and uptime on GitLab.com and other large GitLab instances. In fact, we're already seeing some big performance payoffs as we bring services online.

> Please please don't get complacent. Not yet.

I can confirm that this is not the case. We're focused and working really hard to improve performance and we're also working hard to improve our metrics, so that we can target optimizations where we can gain greatest benefit.

It's also worth pointing out that routinely experiencing 5+ second render times on browsing a repo homepage is outside our 99th percentile latencies for that route. I'd be interesting in digging into it further. Would you mind creating an issue in https://gitlab.com/gitlab-org/gitaly/issues/new (mark it as confidential if you wish) and ping me `@andrewn`.

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?

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.

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.

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...

Glad to hear and thank you very much!

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.

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.

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.

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:

   JavaScript 86.45 %
   CSS 6.79 %
   HTML 4.79 %
   Shell 1.07 %
   Lua 0.82 %
   Makefile 0.05 %
   Groovy 0.03 %
   Python 0.01 %

Fair enough: this is exactly what we've moved to on Gitter on Gitter since open-sourcing the product.

(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.

Thank you :)

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

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

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/

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.

Additionally, would love to hear your feedback on what you think we could change in Gitter to make privacy easier and less frictionless.

Sandeep, it's interesting that you view it that way, but it was never our intention to deliberately make privacy hard. When creating a new room, you can choose to make it public, private and optionally allow anyone from your GitHub org to join your private room. See http://imgur.com/jIb8EKA

It's definitely true that the product focus on Gitter has always been more on public rooms. That's because the focus of our company has always been on the network of public communities, rather than enterprise features, which we feel are well represented in the market by other great products like Slack, Mattermost, etc.

(Background: I'm CTO/Cofounder at Gitter)

Depending on the availability of a Bayeux client for Golang, it looks like something that could be integrated quite easily.

Gitter has been working on a content system called Topics. https://gitter.im/gitterHQ/topics. It's still in Beta, but Q&A and structured content is definitely something that - in addition to chat - we think is important.

(edit: typo)

Thank you Dangeranger! FreeCodeCamp is an incredible community and we've been glad to be able to support them in doing the amazing work that they're doing. Hopefully this announcement will help them go from strength to strength!

Gitter uses a proprietary websocket protocol built on top of the Bayeux protocol: https://docs.cometd.org/current/reference/

More details can be found on the developer site: https://developer.gitter.im/docs/faye-endpoint

We also have an open-source IRC bridge: https://github.com/gitterHQ/irc-bridge

It's a completely unscientific method, but searching through one of our large applications (`npm ls|wc -l` -> ~2000 dependencies), the only modules I can find using `uv_queue_work` are:

* kerberos, unused (dependency of mongodb)

* protobuf, for serializing data

* snappy, for compression

kerberos isn't actually used in our app, so it doesn't matter, but we send a lot of data through protobuf and snappy, so it may be worth us profiling this a little more.

Thanks for all the brilliant support Pavan!

In fact, Gitter uses Pavan's excellent Octonode library (https://github.com/pksunkara/octonode) for all it's communications with Github.

Hi, this is Andrew from Gitter.

And we completely understand. We're waiting on Github to update their OAuth scopes, and we understand that they're working on it.

If you're not comfortable with the OAuth permissions Gitter requires, you could try Gitter's sister product, Troupe https://trou.pe. It's got most of the same features, but with less Github integration and no markdown or syntax highlighting.

Hi, this is Andrew from Gitter.

If you're not comfortable with the OAuth permissions Gitter requires, you're welcome to try it's sister product, Troupe https://trou.pe. It's got most of the same features, but with less Github integration.