I was sucked in by Gitlab's feature list and marketing. But holy shit so many things are half assed and so many features are buggy and broken. Like their wikis would sometimes just straight up delete text and their webhooks would break images. I started a bunch of issues but they really have no chance of getting fixed anytime soon. Just shows how different your impression of something is after actually using it.
Our teams evaluated Gitlab for a year before completely migrating away from it (to Github Enterprise for SCM, Confluence for wiki, YouTrack for issues and TeamCity for CI).
Not a single team (out of 20) was happy with the overall performance (and especially the performance of code search).
As far as wiki is concerned, Confluence's UI has its own share of issues, even after their recent overhaul, but all in all it is much better product. YouTrack and TeamCity are simply much more polished & stable products and are (in our experience) easier to administer than the competing offerings from Gitlab.
> Not a single team (out of 20) was happy with the overall performance (and especially the performance of code search).
Hi! I'm the current PM for our search and as Sid mentioned we've steadily been working to improve that. It's been getting a lot better, but most of the improvements are heavily reliant on also having Elasticsearch enabled. Without that, there's really no way for us to provide a optimal search experience for the amount of data and content there.
If you have any specific search feedback, please feel free to open an issue or reach out to me @phikai on GitLab.
I don't really use gitlab, but I wrote my own git implementation recently (https://github.com/oridb/git9), and I've had bug reports when people tried to use it on gitlab.
Apparently it can deadlock processes on the server, stopping the clone -- and they never get cleaned up. While they don't prevent anyone else from using the machine, they do sit around wasting resources, and potentially causing a denial of service attack.
I figured out bugs for github's issues, but I haven't been able to find one for gitlab's, and they've been pretty silent on the bug that someone else filed about this as far as I can tell.
It didn't feel like a particularly easy to trace system when I tried debugging.
My impression is the opposite. Compared to Github, Gitlab is simply phenomenal, especially the UX. It's honestly one of the few pieces of software that I truly enjoy using every day.
Besides, if you manage to find their issue you'd see carnage this decision caused for some of the customers. Even those with own runners found them swamped in jobs doomed to fail , blocking actually inportant pipelines.
Autodevops as a product feature targets very niche audience of teams running gitlab, but without dedicated DevOps team , it is by definition a very opinionated view on CI/CD and I can not see how it was acceptable to suddenly enable it on all existing projects on whole gitlab.com overnight.
I agree with you, we don't currently cover all the use cases we'd like to, but we're working to expand the feature set and technologies we cover.
If you had a particular use case that was not well covered, I'd love to learn more about it so we can evaluate related improvements. You can reach me at daniel at gitlab dot com. Thanks.
The wiki is GitLab should not delete text, please file a bug if you had dataloss.
The current state of the wiki isn't great but we're also not seeing a lot of people care about it. Many people are switching to static websites. Therefore we're not investing to get the wiki better than the current state of a half circle.
A wiki's not the same usecase as static site, a static site is for marketing and wikis are for project management. I mean maybe people would use it if it weren't crappy? I would've been happier if the wiki didn't exist and I didn't invest time into wrangling it. ATM it's just a frustration.
It's not dataloss but it deletes text in the same line as wiki internal links. And what kind of wiki doesn't use lots of internal links. https://gitlab.com/gitlab-org/gitlab-ce/issues/67132 This basically makes the wiki unusable but it's marked as "backlog".
If you really do feel this way about the wiki then it should be clearly marked in your marketing. I read about your "integrated devops experience" and was onboard, but if your intent is as you say then you need to put parentheses next to the wiki feature item list that says "this is crap and we intend for it to stay crap" and we'll know to value it appropriately when choosing a provider.
I'm surprised that this wiki bug that two people here mention has only one upvote https://gitlab.com/gitlab-org/gitlab-ce/issues/48641 I'm not sure if the complaints are over multiple issues, if the wiki doesn't get a lot of usage, or something else is going on. The bug sounds legitimate.
> A wiki's not the same usecase as static site, a static site is for marketing and wikis are for project management. I mean maybe people would use it if it weren't crappy? I would've been happier if the wiki didn't exist and I didn't invest time into wrangling it. ATM it's just a frustration.
Hi! I'm the current PM for our wiki's and I agree that the experience isn't up to par at the moment. As Sid mentioned, historically wiki's were not a priority as many users weren't coming to GitLab for those features. We're starting to see shifts in that thinking as we've penetrated deeper in to some markets so we're working to adjust accordingly.
> It's not dataloss but it deletes text in the same line as wiki internal links. And what kind of wiki doesn't use lots of internal links. https://gitlab.com/gitlab-org/gitlab-ce/issues/67132 This basically makes the wiki unusable but it's marked as "backlog".
That issue is interesting because it's a link mechanism that relies on the underlying wiki project that we use. (i.e. that's no common markdown syntax). Discoverability of things like that is limited to some power users who know that we're using Gollum underneath and know of some of the supported syntax. What we've seen is that most users don't use that functionality and instead just use absolute links in markdown. This likely explains why the upvotes are so low on the bug report as well.
As an FYI, I've also asked a couple of our engineers to take a look at that specific issue to see if it's something that can be relatively easy to fix. No guarantees on anything here, but we'll try to get a bit more relevant engineering information to assist in understanding scope.
> If you really do feel this way about the wiki then it should be clearly marked in your marketing.
That's a lot of what our maturity pages are trying to do. We're being honest with ourselves and with our users about where we think the functionality of certain features are. In fact, when I started we had the Wiki listed at a `Complete` maturity which I reduced to viable: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...
If you take a look at the wiki strategy (https://about.gitlab.com/direction/create/wiki/) our next focus is going to be on making editing easier and improving navigation. We think these things will start to move the conversation forward for users and we'll see more adoption.
Even more, if you think we're not moving in the right direction with the Wiki's please be vocal on the issue tracker, or open an issue for the Wiki Strategy or even a merge request to change something. We're happy to have the feedback, and don't hesitate to tag me on wiki issues I'm @phikai on GitLab as well.
Thanks for explaining and for taking another look at the issue. Your comment makes sense to me in context of your company's strategy. I'm not saying that's wrong, as surely the breath allows you to gain an niche that is less competitive and less risky than a depth strategy that forces you to compete head to head with great products like notion... but as this thread shows it has enormous downside.
But anyway the double brackets is not a Gollum feature. It's a wiki thing, going back to wikipedia.
Since you're here I think this issue is also misprioritized: https://gitlab.com/gitlab-org/gitlab-ce/issues/66898 You should reconsider as a lot of integrations rely on webhooks and broken images make the whole thing impossible.
> But anyway the double brackets is not a Gollum feature. It's a wiki thing, going back to wikipedia.
That's fair, the point was that it's syntax specific to the wiki system vs. the rest of our markdown filters.
> Since you're here I think this issue is also misprioritized: https://gitlab.com/gitlab-org/gitlab-ce/issues/66898 You should reconsider as a lot of integrations rely on webhooks and broken images make the whole thing impossible.
I'll take a look at this - it popped on to my radar recently but I need to dig in further to understand the use case and functionality here. Thanks for bringing it up.
Perhaps an argument for focusing on doing a few things well?
I work for a GitLab shop, but we don't use the bugtracker (Jira) or wiki (Confluence), we mostly don't use the CI (Jenkins is just more flexible), and we definitely don't use the container stuff. We currently do use the review workflow but at various points have considered moving to a different tool for that as well.
So yeah, we would have been fine with a GitLab that did less— a lot less, and instead prioritized supplying first class integration points and supported plugins for other best-in-class tools.
Hi there! Just wanted to add my two cents here. Just like you choose to use SCM and workflow review, we have a lot of other users and customers utilizing different permutations and combinations of the various stages. Over time, various stages all move toward maturity, some faster than others. I know this is a different model than most software companies and it has its downsides. But the net positive is that we are able to provide an increasingly unified experience for DevOps. Note that at other companies the same thing happens except they market different stages as separate "products". They gain on the marketing but lose on the ultimate user benefit (again, IMHO).
I would much rather have fewer features which work well. For example, until recently there was a restriction that jobs could only run in parallel if they were defined in the same "stage", and no two stages could have running jobs at the same time. This means that a job whose dependencies were met could not necessarily be started because it belonged to a later stage (and jobs cannot depend on other jobs from its own stage, more on that later).
GitLab then introduced another way of specifying dependencies using the keyword "needs" ("dependencies" was already taken by the half-baked implementation). This allows jobs from multiple stages to run concurrently, as you would expect. However, you are still required to shoehorn your jobs into stages, even though they should be completely deprecated by now. Worse, the restriction that jobs cannot depend on other jobs from the same stage still remains. On top of that, the visualization of a pipeline pretends that the new way of specifying dependencies does not exist, so all the arrows between the jobs are meaningless.
I would much rather have had a proper implementation of the simple, more general approach, than having to deal with the legacy of a hacky and half-baked solution.
We released DAG as an MVC, which helped a lot of people out even in its current state. We do release features here iteratively intentionally, with the idea that feedback will help make future iterations better in unexpected ways compared to if we released a big feature all at once.
The items you mention are scheduled for follow-ups in our epic https://gitlab.com/groups/gitlab-org/-/epics/1716. Your feedback on sequencing or how we are approaching the different improvements is more than welcome.
I would have loved for the feature to be useful for you too in the MVC iteration, and I'm sorry it wasn't. We are still working on it, though, and I hope that it does become valuable for you also. In the meantime you should still be able to use GitLab in the same way you always have - let me know if you're having trouble running pipelines without the DAG.
It's not that the DAG feature isn't useful to me, the problem is that it has to coexist with a badly engineered version (the stage based model) which should never have been released in the first place. It is better to have GitLab not support CI runners than it is to push something that is so badly engineered. Better to delay that feature for 6 months than to increase the amount of legacy you push downstream to your users.
Also, this is just a single example that I pointed out to outline what I think is a problem with the whole development culture around GitLab, which puts too much focus on releasing early, and too little focus on quality assurance. Of course, you shouldn't spend years perfecting the next release, but you release too many features too early for my taste.
Ah, I understand. We do have users who prefer the stage model or hybrid DAG mixed with stages, but I get that that isn't your point of view. I do hope that after the next couple releases it becomes something more useful for you - your use case is important too.
Releasing early to get feedback on issues is important to us but we can do better communicating around what's an early preview vs. a mature feature. The maturity page that's linked to in this discussion is actually part of how we are trying to improve our communication around that. This is more at the stage and category level, but features have a maturity level as well and it's worth us reflecting on how that can be made more clear.
Sorry if I am a bit frank, but I simply do not believe you when you say you have users who prefer the "hybrid DAG mixed with stages". That's a bit like Microsoft saying that there are users who enjoy the 255 character path limit. My use case isn't an "improved DAG model", it is a DAG model without the pointless restrictions introduced by broken legacy.
In the DAG model (which really is just the model implemented by every sane build tool ever made), stages give you no extra expressive power, they only add arbitrary restrictions to that model and aren't useful at all.
Whole this discussion is mostly about how feedback is not taken into account and customers and users are not heard. Gitlabbers keep using this "release early and then let feedback to shape future " mantra, but in practice it is rarely happen or at least doesn't happen quick enough.
Hi! GitLab employee, first of all thank you so much for the detailed feedback! It's part of my job to relay feedback and make customers feel heard, so I'll talk to my team on ways to improve (you can see my job description here if you want: https://about.gitlab.com/handbook/marketing/community-relati...)
As per your second point, and this is speaking personally and not really officially, I do think our feature goal has been historically a bit too ambitious (although hopefully transparently so: https://about.gitlab.com/company/strategy/#breadth-over-dept...) seeing as how we're barely out of the startup phase. But we have had a big hiring push this year and have almost tripled our headcount (which did introduce growing pains of it's own lol). Once we've stablilized a bit, we will be able to dedicate more resources solely on maturing features.
I hope this doesn't come across like making excuses, these are just my observations as a user-turned-employee. I will take your feedback about not being heard into consideration though so we can improve on that!
It's also an attitude that pushes the cost of wrong decisions to the users, and really it just sounds like an excuse for not spending the internal resources required to do proper designs and quality assurance.
But the net positive is that we are able to provide an increasingly unified experience for DevOps.
The point of the GP and others where that as of now there is nothing positive about the "unified experience for DevOps", it is very buggy and lacking, maybe someday.
I'd rather have no (eg) wiki feature at all then have a half-assed one.
Because _if_ I feel like the feature might be useful, I'm going to try to use it, and invest time in trying to use it, and only then find that it's not reliable or well-polished after all. The more such features there are, the more chance I'll spend at least some time being frustrated by at least one of them.
One of the joys of really well-polished software is that if the feature wasn't worth doing right (and not every feature is!), it simply isn't there at all, so if a feature is there I can count on it being well-thought-out and well-executed.
They love producing public facing verbose process documents... At first I thought, oh these are some neat ideas, but the more that they produce, the more I wonder how they get anything done with so much (verbose) process.
I work at GitLab and can shed some light here. As a 100% remote company we work in all timezone. Writing things down actually helps make things more efficient. At my last job, to get anything done I needed to call a meeting because state lived in people's heads. When someone left, of if you couldn't get them to a meeting, it was very painful. It took forever to get things done because you needed to physically be present in order to work. At GitLab because so much is documented it's easy to pick up state and collaborate with co-workers in all timezones. What's cool, is because it's public, other random people will jump in and help you out that you'd never expect since they have access to everything you have.
Somewhat unrelated, but I’d like to give a shout out to whoever designed Gitlab’s cookie consent interface. Rather than the usual “accept or gtfo” modal they allow you to choose which categories to select, and even list every individual cookie that will be issued, along with the origin, purpose, and expiry. My only criticism would be classifying a few cookies from Slideshare and/or LinkedIn as necessary because they share a name with Gitlab’s own Cloudflare cookies.
At some point tomorrow once I’m on an actual computer I’m going to have a dig and verify that they also don’t cookie you until you’ve consented - if that the case then I’m deeply impressed.
I love using Gitlab SCM, but I'm surprised that Gitlab CI is described as "Lovable" while major bug fixes are gated for months on an uncertain future feature release:
So, can you shed some light on how the actual prioritization works? There are some bugs, one specifically I've mentioned elsewhere, that just get infinitely shoved into the void.
The Product Manager (in the case Jason Lenny who is out of office today) prioritizes between bugs, vulnerabilities, new features, and tech debt. He or she uses customer input, user input, and company input. Read more on https://about.gitlab.com/handbook/product/#prioritization
So, the unfortunate reality of prioritizing customer wants like this is that you're always going to focus on big shiny new features, and not quite so much the smaller (while still important) bug fixes that really need consideration I feel. I felt like I got shoved into a black hole, and it does not inspire faith in your product anymore. Even if I did become a customer, which I was seriously considering before this, we're going to be "too small" to make a dent compared to your bigger customer base.
Existing customers tend to prioritize stability (fixing bugs) over new features.
Please note that even if you're not a customer our issue trackers are open so you can @mention the Product Manager to help them understand the severity and help to diagnose and fix things if you're so inclined.
I agree this issue hasn't been prioritized as high as it should. I meant to indicate that with "This bug took too long to fix." but I should have said it took to long to schedule.
I've always appreciated how open he is, I just wish it never came down to having to flag him down on Hacker News to get something properly fixed (although, I appreciate that is still something I can do).
PM optimizes for his own KPIs, which are at exec level. Given the history of ignoring bugfixes and becoming famous for it, clearly direction leadership sets gives no incentive to fix customers problems.
Hey, I'm Jason - the PM director for this area. I really do appreciate the pings - you can @ me at my username jlenny in issues that are important to you. It's true in general, even for features, but especially for issues a heads up helps us make sure we are prioritizing things in the right order.
You had already been involved in the issue, from what I recall. I also did state my dissatisfaction when it just continued to get pushed back. I get it, bug fixes aren’t glamorous and it’s not fun to work on them, but they still need to happen.
Getting Gitlab CI to work has been a major PITA for me. I would maybe give it a quarter circle in its current state. Not a heart.
The runner self-modifies the config file and uses it as state which makes it basically impossible to deploy it in an immutable way (Like on nixos). I found out that most config options (but not all of them) are also avaible as environment variables and cli flags so that's how I hacked around the issue but it means I can't support all features that the runner has because the environment variables do not expose all the available config options.
The fact that it's so hard to automate a piece of (in theory) stateless software is really annoying :(
Gitlab isn't big company, 100 devs or so, they try to target much bigger fish (>2000 devs) with their product, yet they can't make it work even for their scale: Kubernetes , monitoring, CI workflows like merge trains and others. So when it comes to putting you money (gitlab.com subscribers) where you mouth is (gitlab.com/features page) they are not there yet.
Kubernetes story is quite telling. They released "cloud native charts" a year or so ago , that is their official way to run Gitlab on Kubernetes, yet when they just dip their toes into kubernetes world, when they switched their docker image registry to run on kube, they've quickly discovered glaring omissions like missing liveness probe and storm of errors on any version update. That is what their customers were sold under the label "ready for Kubernetes".
Their product marketing pages always remind me of those "kitchen nightmares" shows.
On this episode, an over-ambitious family restaurant decides to expand like crazy and ends up with a huge menu of stuff that the overworked chefs can't cook properly.
Some TV chef should be yelling at them for wasting the opportunity of a lifetime by ignoring good business sense, or something like that.
Hi! GitLab employee, since the OP mentioned something from a year ago I thought it might be worth mentioning that we haven't been this size for very long. Around this time last year we were at 300ish employees, but we've almost tripled this year thanks to a huge hiring push.
> yet when they just dip their toes into kubernetes world, when they switched their docker image registry to run on kube, they've quickly discovered glaring omissions like missing liveness probe and storm of errors on any version update.
You are right, we had some missteps with the Helm chart that were unfortunately not discovered by others or us. Our test cases of scaling registry up and down worked perfectly in all our synthetic tests we did so it was not obvious to us that the liveness probe was missing. In hindsight it is quite obvious but at that time we had 16 other charts to write and some things did slip through. For a number of other services, community and paying users were reporting issues that we solved as we went further. Registry is one of the components that receives traffic in bursts so for majority of users this was probably never an issue or it was one of those "gremlin" moments.
For GitLab.com the things are quite different. We hold 2PB of data in docker images alone and there is continuous flow of traffic. For GitLab.com scale, none of the services we are porting to K8s have the luxury of the bursty traffic so we are careful in how and when we switch over traffic. The good thing is that all the edge cases we found are fixed and now in the Helm charts releases so that users can really put this on k8s as ready. If you are curious on all the issues we had to cover during this process, see the main registry migration epic https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/70 .
It is also worth nothing that over time, the omnibus-gitlab package has benefited greatly from being used to deploy to GitLab.com. As we migrate more of the workloads into kubernetes using the charts, we expect to see some of the same benefits and insights there. See our handbook for more details on how we use dogfooding: https://about.gitlab.com/handbook/engineering/#dogfooding
Every case of dogfooding brings tremendous benefits to the depth and quality of your offering, no doubt about it and these improvements are very much welcome. Issue I have is not with dynamic, but with the current state of affairs, were wide spectre of features are presented as ready, yet they are not as high quality as Gitlab marketing.
(GitLab employee) thank you so much for the feedback! We agree that a lot of our features aren't as polished as they seem to be presented, which is why we hope the Maturity page adds more transparency.
Gitlab is slow. It’s so unbearably slow, even their official server. Guys, why should a static content load after page loading is done? Page loading done, and the code still loads with a loading circle. Why? Just compare it with github. Average 500ms makes a huge difference.
Also gitlab UI is a huge mess. It got all the features, sure. But the UI is not that user friendly. Don’t use flat the wrong way. Use contrasts for buttons PLEASE. Github is sort of flat and their interface is great with adequate use of contrasts.
From what I have heard from users and customers, the self-hosted folks are indeed super duper happy. The nice thing about the self-hosted option is that regardless of how open an employer company maybe about sending data places, devs can try out the product. That's led to our super awesome enterprise adoption to some degree (IMHO).
We are currently working on addressing performance, having a dedicated workstream for testing and measuring performance across the different GitLab versions.
Yeah speed is the only reason why i won't give Gitlab another try. All these features are great. But i don't believe they will help them with market share until they have addressed the speed issue.
After August was filled with performance related problems on gitlab.com, they actually managed to fix a quite a lot of inefficiencies and more to come.
Plus you can make it as fast as you want if self-hosing is an option by throwing more hardware at it.
Gitlab is a great product for self-hosting a GitHub-like service and I'm grateful for its existence. Having said that, I'm not a big fan of their bait and switch approach to feature creep. Every time I try to update our GL I end up in a world of hurt.
No straight upgrade path when you skip major-ish releases. I end up wasting a day sifting through cryptic issues and docs from vague error messages.
Suddenly can't commit because now my branch is "protected" and failed a deploy pipeline I didn't implement courtesy of GL's "vision".
Not to mention all this comes at the cost of increased complexity and resource usage.
I wish there was a "thanks but no thanks" setting to keep our instance the bare minimum without having to adopt features whole hog every time they get inspired to incorporate the next "big" thing.
Hi, I'm a PM for our linux packages. I'd love to learn more about the cryptic issues and vague errors mention.
We've put a lot of effort towards making the upgrades as painless as possible, with few surprises. One way we've achieved this is by requiring users to update to the last minor version, before making the jump to the next major version, as you note. The reason for doing this, is that we add a lot of validation to that last minor package which checks for any deprecated features/configuration.
This way if you try to upgrade with a configuration that would result in GitLab no longer functioning, we abort the upgrade and tell you exactly why, leaving you with a functional instance in the interim.
It was a while ago but the upgrade was from 9 to 11. The first problem was the error message didn't give me a simple command to go step wise through the upgrade like:
----
Please upgrade to the next GitLab version before trying to upgrade to the latest. The command for upgrading to a previous version is as follows:
sudo apt-get install gitlab-ce=10.8.7-ce.0 -V
See the url below for available releases:
----
Going from 10 to 11 was even more difficult because the gitlab.rb file format changed and I was missing required information that was not apparent from the error messages after running "gitlab-ctl reconfigure" (I think the error was Chef related but my memory is hazy, below are the GitLab issues that finally provided a hint). This wouldn't be so bad if my GitLab 10 instance was working but after going from 9 to 10, all I got was a blank page so at this point I had no choice but to go all the way.
After finally replacing the gitlab.rb file with the template and adding back info from the old file, I was able to finally run reconfigure and update as needed. Of course, I was soon alerted by coworkers that their commits were suddenly being blocked for failing a commit pipeline. Overall it was not a fun experience and I'd rather not upgrade GL unless I have to but I also don't want to skip versions if I have to repeat the hellish upgrade process by manually babying the upgrade.
Thanks for the additional information. The `git_data_dir` and gitaly configuration changes are indeed why we've started requiring moving to the last minor version first. The 10.x to 11.x upgrade was the first major upgrade with these checks, but it doesn't look like we captured all the possible scenarios. (We did prevent a few upgrade failures though, based on customer feedback.)
It is very important for the team to ensure upgrades are smooth. Right around 50% of our installations are running a version at most 3 months old, and we want to continue to improve that number so everyone can take advantage of the latest fixes, features, and security updates.
I moved all my repos to GitLab almost 2 years ago. I just use the online version.
One of the main reasons I moved was because of price (free), and the available CI. I use a $5 DO droplet to do all my CI running - which gets me unlimited usage. It's awesome, and has only had to be rebuilt once it 2 years due to unresponsiveness.
I've been a big fan of the CI - I use it to build my Docker images, then they get run on k8s. Note - I do not use the AutoDevops feature - so I really don't know how that works for people.
I pack the `gitlab-ci.yml` file with my main building steps and all the other tasks I need to run: deploying to k8s, deleting pods if necessary, running db migrations, stuff like that. It works great - everything just works at the push of a button. And now that I've ironed out the `gitlab-ci.yml` file, I don't even have to think about it anymore when it comes to a new project.
Honestly - I like GitHub's UI a bit better as it's a little more modern, but with GitLab's free private repos - it just lured me at first and I'm content for now.
I’m growing a bit frustrated with GitLab myself. There’s a bug in their runner that they’ve pushed back god knows how many releases now that causes the runner to spam a ton of (incorrect) warnings into our logs. I get it, we don’t pay for support or the product, but I was sure hoping after many months that they’d either roll back the change that caused this or given us a work around or something ... I guess it’s time I try to learn the code base and hope they actually take my contribution.
Do you have a link to an issue for this? I work on the Support Engineering team and while our central mandate is not committing code, I think this could be something we could address quickly.
This is great, addressing a common and real criticism of gitlab that it seems has been in recent history much more focused on adding features than maintaining quality. The maturity schedule as I see it seems quite slow though, it shouldn't take years for a new feature to have high quality.
"So breadth over depth is the strategy for GitLab the company. GitLab the project should have depth in every category it offers. It will take a few years to become best in class in a certain space because we depend on users contributing back, and we publish that journey on our maturity page. But that is the end goal, an application of unmatched breadth and depth."
My first experience with GitLab, several years ago, felt like it needed this policy. I actively didn't like it, and did not see the point or added value.
Now my experience is exactly the opposite. I like all of the things GitLab does, it is an obvious and significant value add but ... when I have experimented with it in a home lab and elsewhere there were several things which gave me pause, and I've seen the same expressed elsewhere which alleviates doubts I may be wrong.
Now I'm in the position where I like something and hesitate to recommend it worrying that the details will make my life more difficult and my users' lives more difficult and not less, not because of missing big features but because of quality and depth, as you call it. Maybe it's the right thing for your business to go for breadth even for years longer and seek depth in the future to solidify your position. But for now, as a potential user, GitLab might not be right for me, which I think is unfortunate.
Hi there! I hear what you are saying especially if you are considering recommending the full single application. As our maturity model shares, we are better at some stages than others. So I would share parts of the product that really work for you all the time and let people experience for themselves.
If I could have GitLab Mature Edition that was restricted to the high quality more complete parts, it would go a long way. Otherwise shipping a product where I have to sell the good parts and hand-wave the rest as incomplete -- it makes the product much less appealing.
Not sure why NPS is being used everywhere these days. Basically it makes all levels of "bad" just as bad as each other. What's so hard about using distributions?
Distributions are harder to track over time. Coming up with a single metric is really helpful for A/B tests and seeing how your product changes over time.
I've just read all the comments here, it's a roller-coaster ride but is exactly what I saw with my self-hosted GL.
Each new release there'd be a new release with great new features - yay! - followed by 3-4 patch releases to fix the bugs. You eventually get worn down by it and don't bother using these things.
I see the same with other dual licensed stuff. Kong is a good example - bugs that actually stop routing traffic are eventually acknowledged, but with no feedback unless I keep chasing them. However i'll get regular emails with new products. They've got a new Service Mesh they announced recently. There's not a chance in hell i'll use it until they fix the bugs/issues i've reported in the core product.
Hi! I'm one of the product managers at GitLab that will be contributing to the development of requirements management. I don't believe we've decided that it will only be an Ultimate level feature. The label was added to the epic (https://gitlab.com/groups/gitlab-org/-/epics/707) before any conversation had taken place...or even before there were concrete requirements to build requirements management ;)
We do our best to align features with the likely buyer according to our pricing model (https://about.gitlab.com/handbook/ceo/pricing/). Sometimes we don't get it right and need to fix our mistake after a feature is launched based on feedback from our wider community (example: https://gitlab.com/gitlab-org/gitlab-ee/issues/13856). We have been and will always be transparent about our pricing model and our mistakes in aligning new features with it.
If you're interested in collaborating with us as we build out requirements management, we would love that. It will help us build the right features for the right likely buyer. Please leave some additional thoughts on the epic discussion if you have them!
Oh, I don’t doubt that the feature would make most sense in the Enterprise tier, but we’re on Atlassian right now, whose price is often equated to free compared to Gitlab.
Convincing them to spend $20/developer/month is going to be hard. Convincing them to spend $100/dev/month is going to be a whole different ballgame (even if it’s ultimately perfectly great unit economics if gitlab increases productivity by at least 2%).
Thought the same. Let’s try to pick HN’s brain: is there an alternative that you guys use predominantly, that can “talk” with gitlab’s or github’s issues?
Very pretty graphics and a good way to see a complete listing of products they offer.
I fear that GitLab has simply bitten off more than they can chew. They try to implement so many features that many things feel half-baked. Ultimately - those features that aren't finished are useless to paid or enterprise subscribers.
GitHub has been successful because they focused on doing one thing very well. Now that they have established market dominance, they are slowly introducing new features - but in a way that makes them feel like useful pro-level products right away.
I don't know how GitLab recovers from that other than continuing to march forward. If I were them, I would stem the tide of new product introduction and focus on building out what is already there. It's a very ambitious roadmap they have given the number of features they want to implement.
I like the GitLab flow, and I absolutely love the "Create merge request" button in the issue detail. I miss it dearly whenever I'm working on GitHub, and `hub pull-request` isn't quite the same.
I don't like the code review functions: for example when I'm in the changes tab, where I can both resolve discussions and double-check the code, cycling through unresolved discussions breaks every time and I have to go back to the discussions tab where to check the code I have to open the linked diff in another tab.
I don't like the settings UI, with all those "expand" buttons so far on the right side. I mean, there's even one of those buttons in places where you have only one fieldset worth of settings.
Thanks for the feedback. I just spun up a test MR (https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...) to understand if I could quickly see what was bothering you on cycling through unresolved discussions but it seems to be working ok. Would it be possible for you to elaborate a bit more or link me to a MR where you can replicate the breaking functionality?
I did notice there's a bug where the hover text doesn't go away after clicking on the "Jump to first unresolved discussion" button and I've created an issue to fix that (https://gitlab.com/gitlab-org/gitlab-ee/issues/15462.)
My biggest issue with gitlab code review is that it's unusable for large changes and large files. On large changes it sometimes won't even show all the changes.
Also the auto-collapse size is far too small, and the fact you can't even see the diff for some large changes in infuriating. It makes using it for code review a struggle. My company is trying to move us all to gitlab-ee, but the lack of features and polish to the code review tool is preventing some teams from making the jump.
I feel like the code review portions are more like a half-circle, and not a heart. There are so many deficiencies that make it unusable for large projects.
If I were gitlab I would look at gerrit for inspiration on what you should use for code review. It's ugly, but it's very functional and performs quite well on meager hardware.
I know there are feature requests to make code review more usable but I can't understand how you could dogfood that code review tool and not go insane.
> it's unusable for large changes and large files. On large changes it sometimes won't even show all the changes.
Improving the performance and scalability of merge requests is the priority for the Source Code team right now, and we are starting with progressively loading the diffs over coming releases. See https://gitlab.com/groups/gitlab-org/-/epics/1816. Currently we load them in a single request which is a serious bottleneck.
In parallel we are exploring a range of UX changes to streamline and improve the code review experience. If you have any specific ideas please let us know, or create an issue!
Unrelated to the post but I interviewd with GitLab this year and want to give them a shoutout. The whole process was smooth and the people I dealt with were SUPER friendly, even after I withdrew my offer for another.
Since then, I've moved most of my personal projects over to GitLab and try to evangelise them whenever possible.
I used to use GitLab for my personal projects, but moved away for a couple reasons. The primary one is that GitLab is heavily opinionated, and its opinions differ irreconcilably with my own in a few areas.
Now, most of my code is hosted on GitHub, with a few projects hosted in a Gitea instance that I run myself.
Net Promoter Score. Is a score calculated with a periodic survey that tries to determine cohorts of promoters (people who like your product so much that they are willing to recommend it to colleagues) and detractors (people who hate your product so much that they usually talk bad about your product if the opportunity to do so arises.)
This is calculated through those surveys you get sometimes that say something along the lines of "From 1 to 10 how likely are you to recommend X product to a friend or a relative".. or something like that.
Huh, I'm confused how that score would tell you if a particular specific feature/area of the app provided "an elevated user experience that customers love". Any ideas?
Hmm. Good question. In my experience an NPS study isn't just the survey.
I have done it in the past and usually after you get the results you do a baseline a call/contact your promoters and detractors to learn more about their issues.
So I think it's determined by a combination of personal reach-outs and probably the same questions scoped to particular features.
If you have feedback on some other metrics to use, please contribute! I don't think we've landed on the right formula just yet. But directionally, we'd like these to be based on user outcomes rather than our own opinion.
