Good release, but... I'm getting frustrated of inconsistencies in UI (example -- issue filtering was re-designed in 9.x, but merge requests are still old; search for issues in multiple projects -- old). Unexpected changes, which break existing workflows (un-announced), and so on...
They pushing for new features, but forget to fix old bugs. There are couple of bugs open for months, even with existing merge request to fix -- nobody from engineers take a look until pushed by someone of paying customers.
I hope, Gitlab can pull "Snow Leopard" and do bug-fix only release, and repeat it couple times a year.
@sashk Thanks for the feedback. Your feedback, and others has been heard loud and clear and we've been hard at work this next month. For next month's release (9.4) we were able to tackle just about 100 UI polish bugs. New systems are being put into place to make sure we are polished right out the door, and that the UI is consistent. We want you to love our UI.
Not sure if this has been added to the bug tracker, but when your creating a merge request, clicking the two branches and bringing up the selection boxes used to focus them so you could type into the search straight away. It no longer does, so it needs two extra clicks.
It's small stuff like this that is quite annoying. Great release though, especially with the container registry fixes.
I’d like to report a few issues with the docker containers you provide – currently they don’t run at all, because they claim to require privileged access to several things? It’s not ideal (I’m trying to run GitLab CE on kubernetes, but I’ll likely have to modify it myself anyway to add OIDC login)
Thanks for the feedback. Our current Docker container does require root because it is based on our Omnibus packages.
We are working to create a set of lean containers, one for each GitLab service (Sidekiq, Unicorn, Gitaly, etc.), which will no longer require root access.
I'm also getting frustrated from Gitlab. My company has been on gitlab EE for over a year, and while they have pushed out features quite quickly, their UX is still way behind github. I think they don't have a laser focus on the user and spread themselves thin. There are basic user flows that lack the polish; for example merge requests actually are a pain to edit. If you click the edit button, it does a full page load (instead of doing it using ajax) and the page takes a few seconds to load. So trivial things like fixing the title because of a typo or changing the assignee are actually quite painful. They've hacked a solution by allowing you to some changes through back slash commands but it's still a hack that doesn't address the core problem. Even things like finding all the merge requests where you are listed as an approver is a pain. We have an internal Q&A site and the running joke is that every new hire during onboarding asks the same question "How do I find all open merge requests where I'm the approver" and the answer is always "we don't know". If took them a while to even notify you when your merge request was approved (so you could merge it). Just basic, basic UX is completely unaddressed while they roll out big features like burn down charts, todos, boards. Keep is simple stupid.
It's sad because I want gitlab to win (I believe in both their remote and open source approach) but Github's UX is so much better. We just acquired a company that uses Github so now we have a few engineers using both tools side by side and they all prefer Github's UX at this point so we might switch.
> their UX is still way behind github. I think they don't have a laser focus on the user and spread themselves thin. There are basic user flows that lack the polish
Using both regularly, the whole create issue 1234-> autocreate branch+MR -> git fetch+checkout 1234<TAB> -> code -> git push -> review -> resolve discussions+open issues for unresolved -> merge+autoclose+autoremove branch -> git fetch --prune flow is downright awesome† and really acted as a catalyst. GitHub just feels so antiquated and cranky compared to that so depending on what you're looking for this frustration can definitely go both ways.
† and it'll be even more awesome when we will soon enable per-branch review deployments which get auto-destroyed on branch removal, followed by auto-deploy of master in staging + manual in production, all neatly tracked in the environments tab.
Our UX team has grown considerably recently and this is a big area of focus for us.
In addition to small UX improvements all over the product, we are also doing a massive overhaul to the overall navigation of GitLab starting in 9.4. This work will continue behind a feature toggle for a couple of releases. You can see the work here (https://gitlab.com/gitlab-org/gitlab-ce/issues/32794) and, as always we'd love to hear your thoughts on it, free to ping me directly in that issue on @mydigitalself to discuss.
Thank you for the feedback. We are actively working on making the merge request flow faster and easier to use. We have set up a round of user research to get insight into what works, doesn't work, and how we can make it better. Questions like: >"How do I find all open merge requests where I'm the approver" should be easy to answer and we are working on making that happen.
I would love to have your insights as part of our ongoing research. If you are interested, you can sign up to participate here:
Thanks for the feedback regarding editing merge requests. In this release, we brought inline editing to issues. (So you don't have to do a full page load, like you mentioned.) So we will definitely bring this concept to merge requests at a later release.
Inline editing is important design direction we are heading toward. The benefit is that you don't have to reload the entire page. And of course you can do single tasks, like updating labels / milestones / titles / descriptions all independently and separately, providing a more web-app-like experience, instead of a website experience. Ultimately, it's more usable and efficient.
In particular for the issue / merge request description areas, we want to get to a more collaborative design in the future when you can see other users making changes in super near-real-time, almost like Google docs. Currently, our issue descriptions already are updated in real-time, but it takes a few seconds for you to see updates. So we are working hard in this direction and we appreciate the validation that inline editing makes sense.
Thanks for the feedback. Indeed we recognize the inconsistencies in the UI from search to other areas. Rather than overhaul entire GitLab with each new improvement, we typically apply the change to one area first, and incrementally bring it to other areas as we get more feedback. This also allows us to move quickly and make tweaks. Thanks!
In particular, we've introduced a number of real-time features for issues in the past few releases. We are working to bring these to merge requests soon to get consistency.
I feel like they're pushing hard, so there're more new things to track/change. Last time I installed a local gitlab community server was 8.something, and it's just last year. I understand why my current company just keep local gitlab at older version (V8 I guess).
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-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."
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.
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.
They pushing for new features, but forget to fix old bugs. There are couple of bugs open for months, even with existing merge request to fix -- nobody from engineers take a look until pushed by someone of paying customers.
I hope, Gitlab can pull "Snow Leopard" and do bug-fix only release, and repeat it couple times a year.