HN user

matteeyah

43 karma

Previously: Community Advocate Manager @ GitLab, Backend Engineer @ GitLab, Engineering Team Lead @ Pennylane

Currently: Co-Founder @ OpTonal

[ my public key: https://keybase.io/matteeyah; my proof: https://keybase.io/matteeyah/sigs/yb0djaKvUGJa3MYQ7cSCUIPP8zrV2DtVf5qIxgdiH6U ]

Posts1
Comments27
View on HN

Responding to community questions on social media isn't just a marketing task. Every question should be answered by the employee that is responsible for that part of the business. Your employees will be exposed to direct feedback about their work and your community will always get the best possible response. This is also the best way to ensure that you're building a product that people actually want. See how we achieved this with Respondo [1].

We're just getting started and we'd love to hear your feedback! [2]

---

[1] https://respondohub.com/#explainer

[2] https://respondohub.com/features#feedback

We have some low-level stuff on our roadmap (e.g. federated Merge Requests [1], federated GitLab instances [2], cross-platform mentions [3] - i.e. mentioning GitHub users). These didn't get prioritized yet, but it's only a matter of time. We have limited resources so we have to prioritize and scope out releases in a such a way that it advances both our vision and satisfies customer requests.

A really interesting low-level component that we created and use in production is gitaly [4] (which is a git RPC component that aims to completely remove GitLab's dependency on NFS for repository access - and replace it with gitaly itself).

[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/4013

[2] https://gitlab.com/gitlab-org/gitlab-ee/issues/4517

[3] https://gitlab.com/gitlab-org/gitlab-ce/issues/42230

[4] https://gitlab.com/gitlab-org/gitaly

I genuinely feel this is not the case. GitLab is so much more - it encompasses the full DevOps Lifecycle in a single application. If you haven't checked out our homepage recently, it might be interesting for you to rediscover what GitLab offers - https://about.gitlab.com/

Full disclosure: I work for GitLab, but what I stated above has nothing to do with the fact, it's how I personally see GitLab as a product.

We're working on making GitLab as fast as possible. We have a list of all ongoing efforts to improve performance of GitLab (the product) at [1]. There's also a list of ongoing efforts for improving performance and availability of GitLab.com specifically [2] (performance) and [3] (availability).

As for the differences compared to being on Azure. We don't have any definitive results right now. We'll have to wait for Monday so we can get more performance data. Most likely, we'll have a better image if and how performance changed in the middle of next week. That being said, we did observe an improvement in p95 response time for our web and api nodes - it's a roughly 30% to 40% reduction. We're working on a public monitoring page so you and the community can browse through these metrics at your own leisure.

---

With regards to the Education program - it's now in full swing and available to everyone. You can apply via [4]. We sent out an automated email to let people know it was still in preparation some time ago. It should have been followed up with an email stating that it's fully functional too. Not sure why the university you work at didn't get the second one. Let me know if there's any holdups with your application after you apply through the linked form.

[1] https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

[2] https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...

[3] https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...

[4] https://about.gitlab.com/education/

Could you provide more info about this? What do you mean by "it would hang"? Any specific component that was unresponsive?

Was this on a self-hosted instance or on GitLab.com?

We'd love to make sure this doesn't happen again.

I'll try and clear up any confusion you might have about GitLab. Feel free to ask more questions if I left something out.

I can't find anything describing the relationship between GitLab and Git anywhere on the home page.

The relation between git and GitLab is that GitLab is a front-end for git. However, it's so much more than that. We strive to offer features that encompass the whole DevOps lifecycle - see https://about.gitlab.com/direction/#scope for more context.

We have an integrated CI/CD system, issue tracker with boards and epics, built-in container registry, monitoring and many many others. All of them are listed in https://about.gitlab.com/features/

Likewise, I honestly can't tell whether GitLab is an OSS project or some sort of hosted enterprise "call us for pricing" behemoth

GitLab Community Edition (CE) is a completely open-source project - https://gitlab.com/gitlab-org/gitlab-ce . It's MIT licensed.

We offer a proprietary version with added features - GitLab Enterprise Edition (EE) - https://gitlab.com/gitlab-org/gitlab-ee . It has a proprietary license. Even though it's proprietary, Enterprise Edition is source-visible i.e. you can browse the source.

There's a pricing page with various plans including a free plan, but while I initially assumed they were for a hosted online service, apparently they're for self-hosted.

There's both a hosted solution (GitLab.com) and the option of self-hosting. The pricing page has two tabs - one for self-hosted options and the other for GitLab.com

There is information about many ways to install GitLab locally on different platforms, but it's not clear what you're actually installing at that point or whether you then need some sort of licence to do anything with it.

No matter which package of GitLab (Community Edition or Enterprise Edition) you install locally, you'll always be able to access the free tier of features without a license.

On the features page, each item has two different scales under it, one for GitLab and one for GitLab.com, but I really have no idea what the relationship between those is.

There's four feature / pricing tiers for self-hosted instances: Core (Free), Starter, Premium and Ultimate. From left to right, every tier has more features than the previous one. The distribution of features is documented in https://about.gitlab.com/features/ (upper scale).

If you opt for a hosted solution on GitLab.com, there's also 4 pricing / feature tiers: Free, Bronze, Silver and Gold. All public projects have access to Gold-tier features for free. The feature distribution between these tiers is also documented in https://about.gitlab.com/features/ (lower scale).

There is an entirely separate feature comparison table that is actually linked from the pricing page, but that only shows one of the scales, and suggests that the lower/free tier is quite restrictive.

We prioritize features for one of the paid tiers if we think the feature is more relevant for larger organizations.

You can find out more about our stewardship of the open-source GitLab CE project at: https://about.gitlab.com/stewardship/

Glad to hear you're interested Silhouette!

what exactly is GitLab?

Here's a couple of points that might shed some more light on it: https://about.gitlab.com/about/.

IMHO the first point nails it pretty well: "GitLab is a single application with features for the whole software development and operations (DevOps) lifecycle."

I've always found the web site more confusing than enlightening.

Did you take a look at our homepage (https://about.gitlab.com) recently? (we updated it not too long ago)

Which part of it do you find confusing? We'd love to make it better. If more direct feedback is your thing, you can also open an issue about it in https://gitlab.com/gitlab-com/www-gitlab-com/issues/new?issu...

Thanks for sharing more info about this jbk.

- A way to fork/MR across Gitlab/Github instances: we don't want our instance to become yet another forge, people should use gitlab.com/GH. We would like that people can fork our projects on gitlab.com/github.com and then send PR our way. I understand this is über-hard, but that would be very nice;

We actually have an issue open about it - https://gitlab.com/gitlab-org/gitlab-ce/issues/4013. As the issue label suggests, it's definitely a moonshot, but completely achievable in small steps / iterations.

- Custom Fields, in order to leave trac (such a pain, this service is);

This one's on our radar as well - https://gitlab.com/gitlab-org/gitlab-ee/issues/1906

- Be able to update a MR without push-forcing on the same branch, but with a new branch (that allows better reviewing of older versions).

Could you rephrase this? I think I'm missing the point. You can update a MR with a regular push. You can also browse through different versions of a MR diff (https://docs.gitlab.com/ee/user/project/merge_requests/versi...). A force push "is required" only if your local history doesn't match the remote history.

At GitLab we're building an automated workflow that takes you from zero to k8s called Auto DevOps.

Some of the interaction points between Auto DevOps and Kubernetes are:

- deploying review apps

- deploying production applications

- supporting deployment of staging and canary environments

- monitoring performance

You can also:

- easily create a clusters on GKE through the GitLab UI

- easily install "helper" applications to set up the cluster

- easily install GitLab Runner to run Auto DevOps jobs on the cluster

You can read more about it here: https://docs.gitlab.com/ee/topics/autodevops/

The jabs at the cloud offerring's reliability are valid. That includes both uptime and the horrendous data loss event they had earlier this year. I don't recall anything major after though not knowing about internals, can't tell if they learned from it or have just gotten lucky.

We have a very detailed post-mortem of the database incident we had in January, along with a list of precautions (every one with an issue) we took to make sure it doesn't happen again in https://about.gitlab.com/2017/02/10/postmortem-of-database-o...

We're also actively working on improving our reliability; you can check up on all ongoing efforts in https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...