6 ms·

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 jus

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.

sytse 8y ago
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 sytse@gitlab.com if you're open to a call about your situation.
- wmccullough 8y ago
  I appreciate how dedicated GitLab is to continuously improving the product. Thinking about moving my projects from Bitbucket to GitLab for that reason.
  - sytse 8y ago
    Yay! Thanks for that.
- cheghook 8y ago
  > 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.
  - deleted 8y ago
    [deleted]
  - akerro 8y ago
    >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 8y ago
      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 8y ago
    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/#past-and-current-performance 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-08-02%2006.55.15.png?dl=0 https://www.dropbox.com/s/ymo28t2v4i4jl4x/Screenshot%202018-...
- corobo 8y ago
  > 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
hunter23 8y ago
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 8y ago
  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 8y ago
    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/#merge-request-comments-vuejs-refactor 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 https://news.ycombinator.com/item?id=17671300
    - merb 8y ago
      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.)
jakecodes 8y ago
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.

sytse 8y ago

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 sytse@gitlab.com if you're open to a call about your situation.

wmccullough 8y ago
I appreciate how dedicated GitLab is to continuously improving the product. Thinking about moving my projects from Bitbucket to GitLab for that reason.
- sytse 8y ago
  Yay! Thanks for that.
cheghook 8y ago
> 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.
- deleted 8y ago
  [deleted]
- akerro 8y ago
  >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 8y ago
    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 8y ago
  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/#past-and-current-performance 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-08-02%2006.55.15.png?dl=0 https://www.dropbox.com/s/ymo28t2v4i4jl4x/Screenshot%202018-...
corobo 8y ago
> 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

hunter23 8y ago

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 8y ago
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 8y ago
  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/#merge-request-comments-vuejs-refactor 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 https://news.ycombinator.com/item?id=17671300
  - merb 8y ago
    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.)

jakecodes 8y ago

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.