GitLab 11.4 Released with Merge Request Reviews and Feature Flags | Hacker News Reader

GitLab 11.4 Released with Merge Request Reviews and Feature Flags

about.gitlab.com

68 pointsmunchor21 comments

We just moved our whole company's set of repos to Gitlab (the integration was appealing, so we didn't have to have a half dozen SaaS memberships for Tickets, CI/CD, devops, etc).

But some basic things seem to be lacking, or not working great. I can't just easily go to an issue based on number (I try putting in "#85" in the top search and nothing happens, well nothing happens at all in the top search)

The issues are just the right level of simplicity that we need.

Performance overall is still just nowhere close to Github levels (where everything feels snappy), but I know Gitlab continues to improve this.

Overall I'm happy I never have to use JIRA again.

Please do file issues for any problem you encountered, no matter how small. My experience with them has been positive.

Yes, I just see the team overall as quite responsive to this sort of stuff over the years, so I trust they'll do something about it.

I'll file an issue.

Could you distill your issues with JIRA down to a few items?

I've worked with JIRA and have my own complaints, but I'd really like the perspective of someone else as well that decided that a simpler issue tracking system is better than what JIRA offers.

I've used Bugzilla, GitHub issues, and now GitLab issues, but I still feel like there's an appeal to JIRA that these solutions don't offer, and examining the pain points helps me understand that a bit better.

My issue with JIRA comes down fundamentally to their UI.

I used to be a JIRA power user in the mid/late 2000s. I think that was the pinnacle of it feeling like a very powerful tool. You could do a lot with their table views, filters, saved views, etc. It was easy to add fields, etc. That's when they were an issue tracker and the primary interface for editing things was just a highly customizable table.

Where JIRA started going off the rails is when they started to bolt on Agile methodologies to their existing system (which, in their defense, was where the whole industry was heading anyway).

But the nail in the coffin (for 2 years now) is that their new UI is just so damn hard to use. I find myself CONSTANTLY frustrated with doing very simple things. The app is slow and doesn't feel snappy like an SPA does nowadays.

The other day, I was on a screen share and trying to edit my notification settings (we were bulk editing a lot of stories and wanted to turn off the deluge of emails). I think the two of us in our screen share spent maybe 10 mins trying to find out where to shut down notifications, and failed. The UI is so damn convoluted. It's like the designers won every debate over any UX people, and focused on making things pretty instead of intuitive.

For them to truly compete with today's tools, I don't think they have a choice but to throw out the existing app and start new.

Awesome, I feel the same way.

Just today, we were told to use a specific filter on our backlog so we could plan out the sprint. It took a bit to find it, and they had apparently set up a new board on an existing project so they could track issues in multiple projects. We plan a single sprint multiple projects because our team handles multiple projects (small company).

Since adopting Jira, management kept changing how they wanted to use it (experimenting, can't blame them), and adjusting within Jira has been super painful. I ended up building a couple tools outside of Jira so I could get exactly the view I wanted.

I went through this same process when management kept trying to tweak Bugzilla to get what we wanted, and I even ended up building a simple issue management application. I'm getting that itch again, so I'm just trying to figure out what people hate so I can know what to highlight. I don't think it'll go anywhere, but who knows!

Good luck!

One thing you might want to highlight is all the developer time that's wasted searching for things (or how to do things) in JIRA. It causes frustration and is a true waste of time.

But again, I don't think there's one issue tracker to rule them all. Gitlab's appeal was less about it being way better, and more about it being fully integrated.

> I don't think there's one issue tracker to rule them all

Oh, definitely. GitHub and GitLab issues are both pretty nice. However, they're not meant to be super featureful, and I think there's a niche between those types of issue trackers and Jira, where most people are actually probably better served by something simpler than Jira.

Some very large projects are managed with GitHub/GitLab issues, so there's definitely an advantage there, but they don't work when you want to track other things with them (e.g. hardware design/release process, customer support tickets, etc).

I just need to figure out what people dislike about Jira, then match the most common use cases making Jira's weaknesses my advantages. However, I'm not fully invested in it yet, but we'll see how much I get fed up with Jira/Gitlab issues (I work on projects that use both).

In my previous job we used JIRA as our SCRUM board (cross teams, i.e. product, back, front, data science and design) and GitHub as our VCS. It was working pretty well. I don't get all the bad reviews about JIRA on HN. Not saying it's the best tool ever but it does the job. I wonder if it's because JIRA is more associated to a management tool than a developers tool?

BTW they made a new version (I didn't try it): https://www.atlassian.com/blog/jira-software/the-new-jira-be...

It can be either - I find that most complaints about Jira boil down to the complainer being forced to use a system, the end users of which didn’t get a seat when it was being designed (and so the result is a bureaucratic mess), or, misconfigured and unnecessarily slow and clunky.

That's mostly my reason for disliking it.

We used Bugzilla for a while, but management wanted more integration with other services, and we didn't have anyone in house that we could spare to build it (and plugins didn't exist for it). Jira filled more of what management wanted, so we adopted it.

At first, I (tech lead) sat down with our QA team and we came up with something that worked reasonably well, and developers and QA were pretty happy. Seeing the success, upper management stepped in and wanted some changes. We pushed back sometimes and made slow progress, but eventually upper management took over and started making changes that everyone hated (lots of micromanagement).

However, there are a few tangible things about the product itself that I dislike, such as:

- slow loading times (apparently taking a few seconds to fully load is "acceptable") - too many options for customization, which makes it too easy for management to break stuff trying to do things "the right way" (especially permissions on transitions) - can't remove states from a workflow without copying and replacing the workflow (seriously, why?) - no dark theme (I'm only half joking)

I'm trying to get a feel for what people dislike about it in case my hobby project of building an issue tracker ever gets serious enough to become interesting for outsiders.

At a previous company I worked for, we used self-hosted GitLab, and the performance seemed really great. I haven't ever really used their hosted offering, so I can't tell whether I just had a low bar of satisfaction or if hosted GitLab allocates significantly fewer resources to each tenant than what our single-tenant system had. I would guess it's the latter.

I've also heard increasingly good things about Gitea, which is written in Go instead of Ruby, so I would expect it to have better performance on a given amount of hardware.

Thanks for writing about your experience with GitLab.

Can you tell us which are the basic features that are missing? And what could make your experience more convenient? Actually, could you please open a feature proposal about that over at https://gitlab.com/gitlab-org/gitlab-ce/issues? We'd love to follow up on it.

The "File tree for browsing merge request diff" is a GODSEND.

They messed up Merge Requests about a year ago- they made is so hard to find out what files have changed.

FINALLY they introduced a solution to that!

I've been using Gitlab for a while, and while it's not yet quite as polished as Github, it is rapidly improving and the gap is already far too small to justify Github's restrictive license and policies in general.

I strongly recommend it as an alternative to Github.

Hello, Community Advocate from GitLab here.

Thank you for your comment, we really appreciate your words. It's great to hear your feedback and you can check out the latest data on stability and performance here https://about.gitlab.com/2018/10/11/gitlab-com-stability-pos...

I didn't know GitLab had "Epics".

What's the main differences with "Milestones"? It's not really clear from the doc. We use milestones as SCRUM epics at my job.

I think epic is a grouping of features, while milestone might relate to a release, which might include epics or even just parts of those epics.

Hey Gregoire, that's a good question. Epics let you manage your portfolio of projects more efficiently and with less effort by tracking groups of issues that share a theme, across projects and milestones. On the other hand milestones are a way to track issues and merge requests created to achieve a broader goal in a certain period of time.

Anyway, please check this documentation for Epics https://docs.gitlab.com/ee/user/group/epics/ and Milestones https://docs.gitlab.com/ee/user/project/milestones/

Nice timing :)

They release every month on the 22nd

Reply on news.ycombinator.com