3 ms·

As an EE customer I've been growing quite frustrated over regressions and their EE issues board being basically a black hole where my feature requests/bugs neve

by swozey 9y ago

As an EE customer I've been growing quite frustrated over regressions and their EE issues board being basically a black hole where my feature requests/bugs never get responses. There are so many quirks with Gitlab that I can't even think of them all off the top of my head anymore. I used to update it after a couple of days to the latest release (the Omnibus works amazingly) but now I don't even want to touch it when an update comes out for at least a month or two. It's like they're just steamrolling ahead at 900mph without acknowledging any input from their paying customers. Global/Group variables, I'm looking at you. Dealing with microservices and Gitlab has been incredibly unpleasant since I can't template out variables. And come on, this is simple and absolutely horrendous to our UX. It was completely ignored until I sent in a support ticket regarding it. I do appreciate the prompt response once I sent in a ticket, but it just proved to me that it's completely pointless to submit tickets to the EE board. So what, am I better off sending my tickets to the gitlab.com board? What's the workflow here? I genuinely have no idea. Why isn't there an EE onboarding process and why don't I get support contacts/account managers as an Enterprise customer? In my experience the "Enterprise" issues are what is critical and trickle down into the community releases. That does not appear to be the case with Gitlab. I know these are growing pains from growing so incredibly fast. I'm not asking for instantaneous results. I'm asking for communication. My ticket sat untouched for something like a month before I sent a support ticket in and it was then tagged as a feature request. Are you eating your own dog food, or am I eating your dog food and spitting out bones bone while paying for a quality meal? https://gitlab.com/gitlab-org/gitlab-ee/issues/2124 https://gitlab.com/gitlab-org/gitlab-ee/issues/2124 https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/1539 https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/... -- this guy is TEN months old and asking for a simple command line switch to modify the one, or one of, the few variables not available in the config.toml of a runner (which is bad enough in itself). And no, telling me to run sed after the register is not even remotely the fix/response I was expecting. Not 6 months ago and not 10 months ago. I'm trying to improve your software. "Hey, your car doesn't shift into 2nd gear." "That's okay, if you kick the floor 2nd gear will fall into place." "Ok, well your 2nd gear still sucks and I don't want to drive this car anymore."

sytse 9y ago
We work out in the open on the EE issue tracker. But if you are a paying customer and have an urgent need it is better to contact support to get your issue prioritized. I've asked our support team to comment if we can explain that better and to comment on the onboarding process.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
gitlab_adam 9y ago
Hi Swozey, Adam from the support team here, we'd like to address each of your concerns individually to satisfy you (the customer) and also so we can improve our reporting process overall. * As an EE customer I've been growing quite frustrated over regressions and their EE issues board being basically a black hole where my feature requests/bugs never get responses. As there are no SLAs applied to the issues board often these issues are only picked up once a support ticket is lodged because in this scenario the service engineer will search for an existing issue to prevent duplicates then label the issue and assign a priority level. We would recommend lodging an issue via the support web form [1] instead, with this we will reproduce then document the defect before escalating to the dev team. If you have already discovered an issue or have created a feature proposal, please follow up with the support team and link to your issue so we can assign the appropriate labels and developers to ensure the issue won't fall through the cracks. This process is outlined on our support page [2]. Also information about how we escalate issues can be found at https://about.gitlab.com/handbook/support/workflows/support_workflows/issue_escalations.html https://about.gitlab.com/handbook/support/workflows/support_.... * I used to update it after a couple of days to the latest release (the Omnibus works amazingly) but now I don't even want to touch it when an update comes out for at least a month or two. A recent feature added to GitLab is the ability to do canary deployments[3] which we are testing internally to improve our release process. We always aim to fix regressions quickly however at this point in time we do recommend waiting for a few patch releases before upgrading to the next minor/major release. * It's like they're just steamrolling ahead at 900mph without acknowledging any input from their paying customers. Customer feedback is one of most important decision making tools when deciding on the future direction of the application. We are often looking for advice from the community, a critical example of this is when we decided to remain on cloud infrastructure due to feedback from the community [4]. * Global/Group variables, I'm looking at you. Dealing with microservices and Gitlab has been incredibly unpleasant since I can't template out variables. And come on, this is simple and absolutely horrendous to our UX. It was completely ignored until I sent in a support ticket regarding it. In this regard, lodging a support ticket is the correct course of action, the support team is here to either resolve or triage your issues so that they don't fall through the cracks. If you could please provide the URL of your support ticket then we will be able to review the mistakes that were made during this specific process and tend to them appropriately. * I know these are growing pains from growing so incredibly fast. I'm not asking for instantaneous results. I'm asking for communication. My ticket sat untouched for something like a month before I sent a support ticket in and it was then tagged as a feature request. The application is growing very fast but so is our team. We try our best not to set our SLAs below a level that we believe we are capable of handling. If a support ticket has breached we will be alerted, or if there is a lack of participation on your dev issue then please let us know so we can pick up the slack for you. * https://gitlab.com/gitlab-org/gitlab-ee/issues/2124 https://gitlab.com/gitlab-org/gitlab-ee/issues/2124, https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/.. https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/.... -- this guy is TEN months old and asking for a simple command line switch to modify the one, or one of, the few variables not available in the config.toml of a runner (which is bad enough in itself). We admit that we dropped the ball on these issues. As per our guidelines[5] we should have pinged our product manager Mark P to get 2124 into a Production demo and pinged a CI product manager for issue #1539 (please note that this feature may exist[6], we will assign someone to investigate). Hopefully this addresses most of your issues and please note that we are always improving our overall product, which includes support SLAs and issue resolution. [1] https://support.gitlab.com https://support.gitlab.com [2] https://about.gitlab.com/support/ https://about.gitlab.com/support/ [3] https://about.gitlab.com/2017/04/22/gitlab-9-1-released/#canary-deployments-eep https://about.gitlab.com/2017/04/22/gitlab-9-1-released/#can... [4] https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-the-cloud/ https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-t... [5] https://about.gitlab.com/handbook/product/#who-to-talk-to-for-what https://about.gitlab.com/handbook/product/#who-to-talk-to-fo... [6] https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/common/config.go#L229 https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma...

by swozey 9y ago

sytse 9y ago

We work out in the open on the EE issue tracker. But if you are a paying customer and have an urgent need it is better to contact support to get your issue prioritized. I've asked our support team to comment if we can explain that better and to comment on the onboarding process.

deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]

gitlab_adam 9y ago

Hi Swozey, Adam from the support team here, we'd like to address each of your concerns individually to satisfy you (the customer) and also so we can improve our reporting process overall. * As an EE customer I've been growing quite frustrated over regressions and their EE issues board being basically a black hole where my feature requests/bugs never get responses. As there are no SLAs applied to the issues board often these issues are only picked up once a support ticket is lodged because in this scenario the service engineer will search for an existing issue to prevent duplicates then label the issue and assign a priority level. We would recommend lodging an issue via the support web form [1] instead, with this we will reproduce then document the defect before escalating to the dev team. If you have already discovered an issue or have created a feature proposal, please follow up with the support team and link to your issue so we can assign the appropriate labels and developers to ensure the issue won't fall through the cracks. This process is outlined on our support page [2]. Also information about how we escalate issues can be found at https://about.gitlab.com/handbook/support/workflows/support_workflows/issue_escalations.html https://about.gitlab.com/handbook/support/workflows/support_.... * I used to update it after a couple of days to the latest release (the Omnibus works amazingly) but now I don't even want to touch it when an update comes out for at least a month or two. A recent feature added to GitLab is the ability to do canary deployments[3] which we are testing internally to improve our release process. We always aim to fix regressions quickly however at this point in time we do recommend waiting for a few patch releases before upgrading to the next minor/major release. * It's like they're just steamrolling ahead at 900mph without acknowledging any input from their paying customers. Customer feedback is one of most important decision making tools when deciding on the future direction of the application. We are often looking for advice from the community, a critical example of this is when we decided to remain on cloud infrastructure due to feedback from the community [4]. * Global/Group variables, I'm looking at you. Dealing with microservices and Gitlab has been incredibly unpleasant since I can't template out variables. And come on, this is simple and absolutely horrendous to our UX. It was completely ignored until I sent in a support ticket regarding it. In this regard, lodging a support ticket is the correct course of action, the support team is here to either resolve or triage your issues so that they don't fall through the cracks. If you could please provide the URL of your support ticket then we will be able to review the mistakes that were made during this specific process and tend to them appropriately. * I know these are growing pains from growing so incredibly fast. I'm not asking for instantaneous results. I'm asking for communication. My ticket sat untouched for something like a month before I sent a support ticket in and it was then tagged as a feature request. The application is growing very fast but so is our team. We try our best not to set our SLAs below a level that we believe we are capable of handling. If a support ticket has breached we will be alerted, or if there is a lack of participation on your dev issue then please let us know so we can pick up the slack for you. * https://gitlab.com/gitlab-org/gitlab-ee/issues/2124 https://gitlab.com/gitlab-org/gitlab-ee/issues/2124, https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/.. https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/.... -- this guy is TEN months old and asking for a simple command line switch to modify the one, or one of, the few variables not available in the config.toml of a runner (which is bad enough in itself). We admit that we dropped the ball on these issues. As per our guidelines[5] we should have pinged our product manager Mark P to get 2124 into a Production demo and pinged a CI product manager for issue #1539 (please note that this feature may exist[6], we will assign someone to investigate). Hopefully this addresses most of your issues and please note that we are always improving our overall product, which includes support SLAs and issue resolution. [1] https://support.gitlab.com https://support.gitlab.com [2] https://about.gitlab.com/support/ https://about.gitlab.com/support/ [3] https://about.gitlab.com/2017/04/22/gitlab-9-1-released/#canary-deployments-eep https://about.gitlab.com/2017/04/22/gitlab-9-1-released/#can... [4] https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-the-cloud/ https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-t... [5] https://about.gitlab.com/handbook/product/#who-to-talk-to-for-what https://about.gitlab.com/handbook/product/#who-to-talk-to-fo... [6] https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/common/config.go#L229 https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma...