Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitlab 13.10 Released

about.gitlab.com

Post reply on HN
Print view View original

71–80 of 88 posts

Re: Gitlab 13.10 Released

#71

Post by acdha »

phikai wrote: post #65
ulrikrasmussen wrote: post #32

Earlier quoted context omitted.

So much second this. It actually feels like it is getting slower on each upgrade, and more buggy. Am I the only one who finds that the "go to next unresolved" button now often goes into an inconsistent non-working state that requires a (slow) refresh? Given that I spend most of my time on GitLab reviewing, this is a real pain point for me.

> Am I the only one who finds that the "go to next unresolved" button now often goes into an inconsistent non-working state that requires a (slow) refresh? I don't think I've seen that reported before and we have been working through some interesting to reproduce issues in recent milestones. Would you mind opening an issue for this? Feel free to tag me (same name).

There's an open issue for one thing I notice all the time: the next/previous unresolved commands update some internal state but scrolling and other navigation do not. This means that if you use any other navigation mechanism (e.g. search) the next time you hit “go to next unresolved” button it will instead scroll backwards to whatever thread follows the last one you navigated to using the “go to next unresolved” mechanism even if that's scrolling hundreds of lines back.

Re: Gitlab 13.10 Released

#72

Post by snicker7 »

I use GitLab at work and sourcehut for personal projects. And as much as I like minimalism, I have to admit how /nice/ GitLab is in comparison. But some complaints since some GitLab employees are watching:

- Syntax highlighting (for Python at least) is wonky.

- Changing profile pictures can take hours or days to propagate. Seems like a silly request, but I like changing my profile pic quickly.

- Metarepos (git repos using lots of submodules) are a mess in git and gitlab doesn't make it easier. It's either monorepo or manyrepo with no support for us inbetweeners.

- Frontend perf is snappier than some competitors, but not snappy /enough/.

- The search UI is bad. The widgets get in my way 90% of the time. And its slow.

Re: Gitlab 13.10 Released

#73

Post by wingerd »

crubier wrote: post #53

From my perspective, Gitlab needs to urgently reallocate 90% of its developper force from "Adding new features in 10 different axes" to "Stop adding new features and exclusively work on performance and consistent unified UX". I know it hurts, I know it's probably not what devs at Gitlab aspire to, but I believe it is much needed. Possibly, an entire rewrite of some core aspects are needed. I have a lot of trouble sel…

They have no clue how to fix performance issues. These performance issue have been there for multiple years and users have been asking them to fix these. Instead, their core competency seems to be hire people to advertize and post "thank you" and "we are here to address your issues" kind of messages here at HN. They have a whole army of those users here (you can check past HN threads related to gitlab).

Re: Gitlab 13.10 Released

#74

Post by sytse »

snicker7 wrote: post #72

I use GitLab at work and sourcehut for personal projects. And as much as I like minimalism, I have to admit how /nice/ GitLab is in comparison. But some complaints since some GitLab employees are watching: - Syntax highlighting (for Python at least) is wonky. - Changing profile pictures can take hours or days to propagate. Seems like a silly request, but I like changing my profile pic quickly. - Metarepos (git repos…

Thanks for these! Some people at GitLab are looking at your post.

Re: Gitlab 13.10 Released

#75

Post by john_cogs »

adduc wrote: post #60
john_cogs wrote: post #43

Earlier quoted context omitted.

We use buyer based tiering to decide which tier a feature will reside in. https://about.gitlab.com/handbook/ceo/pricing/#buyer-based-t...

> Free is for a single developer, with the purchasing decision led by that same person > Premium is for team (s) usage, with the purchasing decision led by one or more Directors Doesn't this conflict with the stewardship promise that "The open source codebase will have all the features that are essential to running a large 'forge' with public and private repositories"?

Thanks for the question. I shared it with @sytse and he's putting some thought into it.

Re: Gitlab 13.10 Released

#76

Post by shubhamaggarwal »

phikai wrote: post #65
ulrikrasmussen wrote: post #32

Earlier quoted context omitted.

So much second this. It actually feels like it is getting slower on each upgrade, and more buggy. Am I the only one who finds that the "go to next unresolved" button now often goes into an inconsistent non-working state that requires a (slow) refresh? Given that I spend most of my time on GitLab reviewing, this is a real pain point for me.

> Am I the only one who finds that the "go to next unresolved" button now often goes into an inconsistent non-working state that requires a (slow) refresh? I don't think I've seen that reported before and we have been working through some interesting to reproduce issues in recent milestones. Would you mind opening an issue for this? Feel free to tag me (same name).

There’s already an issue for this: https://gitlab.com/gitlab-org/gitlab/-/issues/281947

Re: Gitlab 13.10 Released

#77

Post by efiecho »

How is the process going with reducing Javascript on the frontend? Simple things like reading replies to issues or merge requests should not require Javascript, it also makes Gitlab feel annoyingly sluggish compared to GitHub.

Re: Gitlab 13.10 Released

#78

Post by efiecho »

systemvoltage wrote: post #9

I am curious, at what point will the features stop? Do we keep adding features until Gitlab becomes impossibly complex to use or onboard anyone? Why isn't Gitlab built like a modular app - add what you want but core should be simple as possible and feature complete. I am afraid but this is how a lot of applications die. Gitlab is starting to get bulky and obese already.

> I am curious, at what point will the features stop?

Zawinski's Law:

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

Re: Gitlab 13.10 Released

#79

Post by ulrikrasmussen »

shubhamaggarwal wrote: post #76
phikai wrote: post #65

Earlier quoted context omitted.

> Am I the only one who finds that the "go to next unresolved" button now often goes into an inconsistent non-working state that requires a (slow) refresh? I don't think I've seen that reported before and we have been working through some interesting to reproduce issues in recent milestones. Would you mind opening an issue for this? Feel free to tag me (same name).

There’s already an issue for this: https://gitlab.com/gitlab-org/gitlab/-/issues/281947

Yes. This is it. Thanks! I wasn't actually sure when it broke, but this issue describes it perfectly.

Re: Gitlab 13.10 Released

#80

Post by malinens »

phikai wrote: post #57
stevenhuang wrote: post #19

I feel that Gitlab needs to optimize for the 90% use case instead of adding more features. For example does anyone else find Gitlabs diff lacking? It makes reviewing large patches painful, with the seemingly constant fetching of individual file diffs and inability to show large file diffs. The UI in general feels sluggish, especially when compared to something like Gerrit or GitHub.

One more thought on all of this - we're currently doing some research on problems users face in the merge request. Feel free to take our survey: https://gitlab.fra1.qualtrics.com/jfe/form/SV_9HQQil77CjHJIC... Bonus... you can enter for a chance to win a $75 Amazon gift card.

Docker runner performance is horrible. By using ssh runner which runs exactly the same docker command I save 7 seconds each time.

Thid leeds to many hacks to get performance needed (jobs are merged in one big one for example). With many smaller jobs some pipelines run sometimes up to 50% slower than ssh + docker.

Also built-in caching is painfully slow. Our self hosted minio instance as custom cache is 10 times faster than Gitlab's local cache and this is absurd.

These are 2 main speed issues with me. As code reviewer large diff bad performance would be the 3rd issue. It lags even with my beefy workstation. Maybe adding JS functionality is needed for files in current viewport? I don't need syntax highlight and comments options on all 100 files at the same time but I want an option to scroll down and this functionality on currently viewed files

Post reply on HN