It's great and impressive how quick Gitlab moves in adding new features.
But if I have a Graphic Design repo it emphasises Kubernetes, Packages and Security features that have zero relevance. And there is no way to disable them.
And that on every single repo it places these Add License/Contributors etc buttons front and centre even though for 99% of internal projects they serve no purpose.
Every release Gitlab seriously needs to step back and think about how to simplify the interface. Because it's starting to get a bit ridiculous.
> It's great and impressive how quick Gitlab moves in adding new features.
Don't trust their feature list, they often "forget" to use it themselves. Many of those features are there to tick the box and daze executives, but are barely usable in practice.
It took them a year to start supporting Kubernetes clusters with RBAC, they didn't use autodevops for their own releases, even for simple components, nor any kubernetes integration, monitoring, feature flags, Geo, backup procedure. Who in the right mind is going to enable Web Application Firewall feature, when rules exceptions cannot be configured?
Somewhere in comments here will be reply from Gitlab employee, saying that dogfooding is something they are constantly working on, it doesn't matter. What they should be doing is to update documentation pages with feature maturity level and have a block of links to most popular bugs related to the feature, so that poor devops engineers don't have to rediscover all the pain and come prepared.
Just to be clear, Gitlab is an awesome tool, it is just not as awesome as their marketing wants us to believe.
"What they should be doing is to update documentation pages with feature maturity level and have a block of links to most popular bugs related to the feature"
That is a great idea and I wonder if https://about.gitlab.com/direction/maturity/ meets your expectations. We recently update the criteria for viable and complete to incorporate dogfooding:
- Viable: Significant use at GitLab the company.
- Complete: GitLab the company dogfoods it exclusively.
And thanks for calling us an awesome tool. Hope you don't mind the tongue-in-cheek response at the top of my comment :)
While not the above commenter, I found the reply enjoyable. Thank you.
GitLab had been great for us, though we've had issues around their educational institutions license.. so we can't use a lot of the fancy features... But I've enjoyed ops work more on GitLab than GitHub or Jenkins.
Great to hear you are enjoying GitLab and we value you as an Education Program member. We'd love to hear your constructive feedback on any issue's you've had. In the GitLab spirit, we started the Education Program as a MVProgram and are working hard to mature it. We have an open epic - please feel free to provide input. https://gitlab.com/groups/gitlab-com/marketing/community-rel...
I feel a bit the opposite. I've been totally spoiled by gitlab to the point where contributing to libre github projects has started becoming difficult.
We use gitlab at work and it has been great, though we have really great sysadmins so maybe my perception is a bit skewed.
That being said Gitlab's UI is still commits a lot of UI complications that makes it inferior to github for managing libre projects.
I really wish gitlab would have a stronger push to contests the open-source space but it seems that they have pretty much given up already and focus for enterprise instead. :|
GitHub is an established player in the technology space and has done a really great job at fostering its open source community.
You're right that GitLab is trying to differentiate itself as the best place to scale software, and so it feels like its focus is on enterprises. That's where the open source strategy also currently aligns. GitLab is making the best platform to help open source projects thrive at scale.
I'm the new Sr. Open Source Program Manager at GitLab and was recently hired to build out our GitLab for Open Source program (https://about.gitlab.com/solutions/open-source/). This program allows open source projects to use GitLab's top tiers for free, and it provides assistance to large open source organizations throughout their migrations. We are providing open source projects with GitLab’s top-of-the-line features, that enterprises are using, to help them along their own journey.
As I mentioned, GitHub is doing a lot of great things, and I think that GitLab used to be perceived as merely playing a game of catch up. This is no longer where we are today. We're fast at iterating on our product and are blazing ahead on creating a platform that enables cross-functional team collaboration, and industry-standard features for the full software development lifecycle. We're working on a similar strategy with our open source offering -- so that we're not playing catch up, but are instead defining a new standard.
As an open-core company, we have an open roadmap for our product and for everything else we do. If you have ideas for our community relations team (I'm part of this team), we welcome your feedback! You can reach us via our forum: forum.gitlab.com, and via community@gitlab.com. You can also read all about what we do and how we work here: https://about.gitlab.com/handbook/marketing/community-relati...
> Who in the right mind is going to enable Web Application Firewall feature, when rules exceptions cannot be configured?
Currently we are using ModSecurity for our Web Application Firewall and rather than duplicating their documentation, we refer our users to ModSecurity's documentation for rule configuration. Rule exceptions with GitLab's WAF are possible as documented on the ModSecurity website: https://www.modsecurity.org/CRS/Documentation/exceptions.htm...
It is also worth noting that we are in the process of designing a more refined, UI-based policy management experience. While this policy management experience is starting with support for Cilium Network Policies only, we plan to eventually add support for WAF rules as well. We would love to get input or feedback you have on the direction we are headed with our policy management interface at https://gitlab.com/groups/gitlab-org/-/epics/3403
We've actually been using feature flags for quite a while for some release tooling related projects. Geo has been used in the past when we migrated to Google Cloud if I remember correctly.
I think we can stop recommending License and Contributors since GitLab is mostly used for closed source software. The templates will still be there but just not suggested until you started to create a new file.
And you should be able to disable everything but the repo if you want to. And of course you can disable the repo as well if you just want the planning features for example.
BYW There is also a reply in this thread from a GitLab UX team-member who responds to a comment about the thumbs up/down and report abuse buttons https://news.ycombinator.com/item?id=23606854
+1 At my last place, we deployed via Nomad and not Kubernetes, yet we had "AutoDevops" on every repository page and developers trying to use it/ask questions about it.
Being able to wholesale disable features across the install would be a good first step.
It feels very cluttered these days.
I really wish I could disable features on a group/project basis and have those things just disappear from the interface. Ideally by a simple list of toggles.
Mostly I only use the Git, CI, Readme rendering, Docker registry and that's about it. Everything else just gets in the way and makes the interface harder to navigate.
TIL! That is awesome and as a customer/user I'd love to see internal recognition, too! Maybe this would detract from the actual efforts of the other employees but it doesn't necessarily have to be employee of the month - could just be Kudos to X and Y for knocking out this lingering bug or adding this most wanted feature.
I agree recognition is important. We have an internal #thanks channel that got 20+ posts today of people being thanked. Also more than 10% of the company gets a $1000 discretionary bonus every month. We're doing an experiment of making videos for some of these bonuses that optionally can be made public.
If anyone from GitLab is reading this, these pages are locked in a refresh loop. I can't read the content because it is scrolling/moving slightly with every refresh which is happening constantly.
Latest version of Chrome stable, uBlock Origin in default config, HTTPS Everywhere, React/Redux devtools are the extensions I have installed.
I let the page run for 30 seconds and:
* CPU usage on two cores was at 100%
* 2,943 requests were made for 319 MB of resources over 30.06 seconds
A staggering rate of 100 requests per second that persists indefinitely - I have no reason to believe the refresh loop is broken at any point.
I can't seem to reproduce this - maybe it's uBlock Origin? Are you sure it's the default configuration? What were the requests to - just to the main HTML page?
@AaronFriel try deleting your cookies for the website and see if that resolves it. I recall someone at GitLab having that problem the other day and think I recall that clearing their cookies fixed the issue for them. Either way I'll notify our marketing website team to have a look at this.
Welp, this is confirmation that I haven't been keeping up on everything going on; when I learn about my most desired feature on my company's software from a Hacker News post :S
Yay! Tbh I like what it looks like with Dark Reader better: the background is still to bright to my eyes. Any word on when the dark mode will be ready for HN? I saw there was a thread a month or two ago about this.
Being all-remote makes it harder to get acquired. Even if the acquirer is forward thinking, there are many complications to be addressed (compliance with existing hr/payroll/etc).
Last I've checked Gitlab was en route to IPO which makes sense given their unique structure.
I actually have no idea, but isn't "open core" a turn-off to would-be acquirers as well, since the core can fork out from under them if they try to work too hard against the wishes of the community? Maybe there have been open core acquisitions. I don't follow startup news that closely.
With every release I wonder why our team is even paying for Gitlab Bronze. It seems to offer no value at all, might as well go for the free tier and save a thousand dollars a year.
Gitlab needs to be able to mix licenses on a single system, its current model requires all accounts in an org to operate at the same level, try selling a 1000 seat ultimate license at 99/user/month to tbe average sme. In all companies there are seats that need different levels of capabilities, gitlab is just way to expensive to use at anything above starter, the premium level works out at 2x more expensive than jira/bb/confluence with considerably less capability. I want to be able to buy 200 starter, 50 premium and 5 ultimate licenses and mix them on the same system.
They explicitly said they don't want to do that, for reasons that really aren't clear. There are a LOT of companies that want to be able to mix developers and reporters, but can't because the price is astronomical for zero benefit. So they live with a lower tier (likely free).
Yes, this update basically reduced the value of Bronze significantly as there were no relevant new features coming to Bronze and those that we were paying for are now in the free tier.
In general our "Why Starter" page has some great rationale for why we encourage small teams to utilize GitLab Starter/Bronze. https://about.gitlab.com/pricing/starter/
Same boat, although with GitHub pricing changes it’s more advantageous to switch. The fact that the security and dependency management is locked at gold when they are free on Github is annoying.
If only Bitbucket wasn't a typical Atlassian disaster it might be more popular. I've never used an Atlassian product that wasn't one of the slowest websites I've ever seen with an over-complicated UX that can only be described as sadistic (have you seen the multiple settings pages?).
Gitlab and GitHub both blow Bitbucket out of the water, it's not even a competition.
I think that GitHub has a much better UI than GitLab. GitLab is slow and bloated compared to GitHub. Requiring Javascript for browsing the code repository is just bad design.
GitLab employee here. As much as it pains me, I have to agree with you for the most part. Performance is one of the biggest pain points for our frontend team, but is something we're actively working on.
We're in the process of migrating parts of our codebase from haml templates to Vue apps, which does have the unfortunate downside of requiring javascript to run. We're looking into solving this with server side rendering, but it's early days right now.
Well, that's interesting information. I believe it when I see it, but it could be that my criticism of GitLab is no longer valid at some point in the future.
IMHO, it's integration. znpy was correct, but incomplete: GitLab ships with CI/CD, secrets management via Vault, AWS ECS integration, Kubernetes integration, issue tracking, wiki, an artifact repository for 5 major package types, metrics, alerts, and even a full-blown Slack competitor (optional, of course)
You can absolutely integrate your favorite, and/or best of breed, tools with any git hosting software that you'd like -- but that takes non-zero time to do and upgrading them will also be non-zero time. GitLab ships like a machine every month, and it seems this feature announcement is representative of the caliber of every release
The alert integration looks interesting, but the screenshots for code intelligence look awful. Who decided to use a super light shade of gray on a white background?
Their UI has a lot of these annoying issues and they never seemed to get around to fixing them.
My other favourites:
1) UI is all muted and grey which is great because it allows you to focus on your code, issues etc. Well except for the Thumbs Up/Down buttons which are a bright yellow and the only thing to stand out. And it's a feature that serves no purpose in most cases.
2) Report Abuse button is next to the New Issue button. But it's given the same size and prominence. Is abuse really as common as creating new issues ?
3) Backgrounds. Some are light grey. Some are dark grey. Some buttons background is filled, others solid.
Thanks for adding your thoughts, hopefully I can shed some light in a few places.
1) I’m assuming you’re referring to the emoji buttons. They are useful to determine upvotes and downvotes on issues and merge requests. These counts can be used when sorting for popularity. We leverage system emoji here and in most cases they are a bright yellow (https://emojipedia.org/thumbs-up/). It’d be possible to use our custom icon library (http://gitlab-org.gitlab.io/gitlab-svgs/?q=thumb-) for these buttons, but then they wouldn’t visually align with other award emoji that can be added inline. Here’s more info https://docs.gitlab.com/ee/user/award_emojis.html.
2) If you don’t have permission to close the issue (or merge request), you will only see the 'Report abuse' button (I’m guessing this is what you’re seeing), otherwise there would be a split button with 'Close issue' as the default option, and 'Report abuse' as the second. I agree that this needs some further consideration, so I opened an issue to start a discussion https://gitlab.com/gitlab-org/gitlab/-/issues/223775. Feel free to contribute and add your thoughts there too.
We do have an issue scheduled in 13.2 for Wiki diffing. However this still won't allow you to revert a change but will visually help you see the diffs line by line (just like in MRs):
Few features (apart from be able to view wiki diffs) from my point of view:
1. Wiki edits in activity
2. User wiki edit history (= edits times, pages, size of diffs)
Maybe in a long run it will be good to have Markdown based collaborative document editing. Meaning that each editor can branch the draft doc, introduce changes.
Then these branches will need to be reviewed and merged, probably by 1-2 people.
But if I have a Graphic Design repo it emphasises Kubernetes, Packages and Security features that have zero relevance. And there is no way to disable them.
And that on every single repo it places these Add License/Contributors etc buttons front and centre even though for 99% of internal projects they serve no purpose.
Every release Gitlab seriously needs to step back and think about how to simplify the interface. Because it's starting to get a bit ridiculous.