[cheghook]

I can't understand why GitLab thinks they have to embark on a new project every so often instead of focusing on their current product and features. There is just a lot to work on, so many of the current features/products are half assed. At my place we moved to GitLab 2.5 years ago and updates where smoother back then but the past few months we had to hire a new sys admin for our build machines and GitLab server to follow on new issues created on GitLab.com and decide if it's safe release and even then he still reports 4-5 issues to GitLab support after every update. We were expecting it to be an easy `yum update` like a normal package but it's just getting worse update after update. It's so bad that my manager asked me to look into GitHub + another CI/CD solution.

[hunter23]

Agreed - our company moved to Gitlab about the same time (2.5 years ago) and it's very clear from their updates that their focus has splintered in different directions. Our company has recently moved to more Microsoft products so I am pushing our CTO to move to Github.

If the CEO is following this, please improve basic user stories like:

* As a user, I want to easily know who has approved my merge request. Note the word "easily". The UI lists the people who did not approve next to label "Approved" and the people who did approve next to the label "Approved by". Makes absolutely no sense

* As a user, I want to see all the merge requests that I need to review because I am listed as an approved (it boggles my mind that this doesn't exist)

* As a user, I want to be notified by todos that only have any pending actions on them

* As a user, I want to disapprove a merge request

There are so many basic areas of the core product that are almost unusable. All of our engineers who have to regularly switch between github and gitlab prefer the github ui.

[merb]

Loading a Merge Request with 168 changes, basically breaks a 4cpu's 4gb instance on gitlab, so yes, "the most basic areas of the core product is almost unusable".

And while some integration is good... A lot of recent stuff is just "we try to grab the easy money"

[sytse]

Yep, load times of large merge requests was a big problem. In 11.1 we launched a refactor of merge requests to solve this https://about.gitlab.com/2018/07/22/gitlab-11-1-released/#me...

That got the time down for the worst case we measure from 15 seconds to 3 seconds, see https://news.ycombinator.com/item?id=17671300

[merb]

we are on 11.1 and it takes way more than 3 seconds (or even 15 seconds) (Request takes around 7 seconds and parsing it, and parsing it takes 10 seconds).

(P.S.: I also have the same source in gitea of a way less powerful instance which basically renders the whole thing in way less than 1 second.)

[victorwu]

--- As a user, I want to be notified by todos that only have any pending actions on them ---

Can you explain further what you mean by "pending actions on them"? We are working to simplify and streamline our notifications and todos in GitLab. In particular, the current thinking is that they are very similar. A "notification" is an email, and a "todo" is a something that GitLab calls your attention to in the Web UI to take action on. So mechanically, they are very similar and we would like to harmonize them.

Our latest discussion is in https://gitlab.com/gitlab-org/gitlab-ce/issues/48787.

[hunter23]

If I have a merge request where I am added as an approver and that code is merged in, then I don't want it to show up on my todos. A merge request has a specified amount of approvals required and when that threshold is hit and the code is merged, there is no work to be done. It is no longer a todo but a done. Unfortunately todos doesn't work this way and become useless for senior members who get listed as approvals for many merge requests.

In terms of combining them with notifications, I agree. I just need a web place to see all the "pending" action items I need to work on. A web notification feature should be the place to see all the pending notifications left for me (similar to how it would work on email except you can't expire emails).

[jramsay]

Thanks for taking the time to share your feedback. I'm the Product Manager responsible for merge requests. Approvals are such an important part of merge requests, and we are working to make them better.

We've improved a number of confusing approval widget states in GitLab 11.2 (https://gitlab.com/gitlab-org/gitlab-ee/issues/5439) which will ship later this month in and the ability to filter merge requests by approver is in development by a community member (https://gitlab.com/gitlab-org/gitlab-ee/issues/1951).

This is just the beginning though – code reviews and approvals are at the heart of the daily workflows of writing software and we'll be continuing to make them even better. I'm particularly excited about more structured code reviews with batch comments in 11.3 (https://gitlab.com/gitlab-org/gitlab-ee/issues/1984), better navigation between files in merge request diffs with a file tree in 11.4 (https://gitlab.com/gitlab-org/gitlab-ce/issues/14249), and our first iteration of code owners (https://gitlab.com/gitlab-org/gitlab-ee/issues/5382) also in 11.4.

Thanks for the disapprove merge request idea. We're considering this idea in https://gitlab.com/gitlab-org/gitlab-ee/issues/761 where further feedback would be much appreciated, or on any other issue.

[hunter23]

Hi - thanks for responding!

I'd point out that if you look at issue 5439 the team itself was originally unaware of the high number of edge case states of the merge request and closed the issue prematurely. Having many code paths is a code smell so I'd suggest simplifying your UX and edge cases here.

Since you own the merge request flow, I would suggest looking at the page and all it's edge cases and seeing where you can simplify for the user. There is a dizzying large amount of info and CTAs presented to the user; it's pure information overload. Don't just measure yourself by how many features you ship but rather on how you communicate those features to your users. Simplicity is a powerful feature in itself.

Looking forward to batch comments.

The disapprove merge request is a feature available in Phabricator and other competitors so I would look to see how they've implemented it.

[sytse]

I'm sorry to heard your experience with GitLab hasn't been smooth. We have more people then ever working on the core of GitLab. And the number of reported issues per customer are going down. But every problem is one too many. Please email me at [e-mail] if you're open to a call about your situation.

[cheghook]

> And the number of reported issues per customer are going down.

This doesn't mean anything, maybe the customers are simply tired of reporting issues. For example last year we didn't do any updates for 6 months because we were afraid it'd break something and we were too busy to be willing to spend the time reporting problems.

We also don't report issues that are already open on gitlab.com, reporting the issue means your customer is willing to spend time reporting, following up and testing your bug. This is your job, not the customer's. At the moment we are only reporting issues that are either blocking us from work or slowing down our development. The majority of issues we are facing are performance problems.

I just wrote a script to plot the number of issues on gitlab-ce over time and percentage of open/close issues, and the overall period they have been open for, you are accumulating issues with: `backend`, `UX`, `technical debt`, `performance`, `CI/CD`, ... labels, a lot of them don't have a Milestone and have been open for a long time.

I am not sure how emailing you would help us, it's not like the problems are not reported or you don't already know about them. It just appears that the priority of GitLab, as a company, is not shipping a quality product anymore.

EDIT: I work in the aerospace industry and one of the stages of our pipelines is to run stress test on our product. I would suggest you to run a stress test on an instance of GitLab, this would be an amazing place to start looking for performance problems.

[akerro]

>maybe the customers are simply tired of reporting issues. For example last year we didn't do any updates for 6 months because we were afraid it'd break something and we were too busy to be willing to spend the time reporting problems.

We just stopped upgrading GitLab over 2 years ago, we're on 8.9

[sytse]

We're correct metrics of how frequently customers upgrade and as far as I can tell it is way above industry average.

I'm sorry to hear you experienced to much breakage. Can you maybe point to a regression or two that stayed open too long or that caused you a lot of trouble so we can learn from it?

[sytse]

Can you maybe share the plot you made and/or the code you made it with?

As GitLab gets more popular I'm not surprised the number of issues grows.

We are measuring a lot of metrics on GitLab.com. And we are shipping a lot of performance improvements to improve those metrics. https://about.gitlab.com/handbook/engineering/performance/#p...

For example a really big MR had a time to first byte of 15 second. It now is 3 seconds. https://www.dropbox.com/s/ymo28t2v4i4jl4x/Screenshot%202018-...

[wmccullough]

I appreciate how dedicated GitLab is to continuously improving the product. Thinking about moving my projects from Bitbucket to GitLab for that reason.

[sytse]

Yay! Thanks for that.

[corobo]

> the number of reported issues per customer are going down

Couldn't that just be because you have more silent customers now? Probably from the people moved their projects from GitHub

[jakecodes]

It is truly a bummer that you feel you are receiving half assed updates and features with constant problems.

The size of the GitLab is constantly growing and Meltano is adding to GitLabs capabilities, not subtracting. We've hired 2 very awesome Python developers for Meltano specifically. They each have tons of experience in the ELT space.

All this to say, that no one at GitLab has turned their eyes away from GitLab, it's the opposite. This business is here to help GitLab as our first customer. Rather than having GitLab struggle to get it's data tools together, and make business decisions based on that data, we've devoted a whole team to provide a solution while helping the community at the same time.