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_....
* 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.
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.
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_....
* 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-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 [2] https://about.gitlab.com/support/ [3] 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-t... [5] https://about.gitlab.com/handbook/product/#who-to-talk-to-fo... [6] https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma...