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

51–60 of 88 posts

Re: Gitlab 13.10 Released

#51

Post by mkarampalas »

Operyl wrote: post #46
kennyGitLab wrote: post #37

Earlier quoted context omitted.

Here is the MR for 13.10 What's New Content. You'll need to update to the first point release after 13.10.0 to get this content. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/57119

This seems really bizarre to not be included with the .0 release. The features are live, but the label states "Your instance (current version) is 13.9". It could do with some more refining perhaps.

Hi Operyl, GitLab PM here. Thanks for the feedback on What's New. As you point out, it looks like we have some opportunity for refinement and better/clearer messaging for folks that update right away to the .0 release. I've opened up this issue to track that work and welcome your feedback or ideas there. Thank you! https://gitlab.com/gitlab-org/gitlab/-/issues/325591

Re: Gitlab 13.10 Released

#52

Post by diegocg »

john_cogs wrote: post #45
diegocg wrote: post #35

Earlier quoted context omitted.

The thing I miss the most from the reviewing process is the ability to review diffs per-commit. This is closer to how git is used in the linux mailing lists but gitlab completely breaks that workflow. Github has added some support for that. And yeah, performance sucks, even for trivial patches.

When using merge requests, each push to a branch creates a new version. You can then compare between any two versions and review the diff. Documentation: https://docs.gitlab.com/ee/user/project/merge_requests/versi...

Not very helpful unless you push every commit individually

Re: Gitlab 13.10 Released

#53

Post by crubier »

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 selling Gitlab to my team. Everyone just wants to move to Github to have a simple UX that works.

Re: Gitlab 13.10 Released

#54

Post by phikai »

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.

Hi! Thanks for the feedback on diffs - it's something we're always thinking about and working on in the group.

One of the things we're currently working on is putting monitoring in pace for all the of the diff limits - https://gitlab.com/gitlab-org/gitlab/-/issues/31063. The goal here is that we can further fine tune some of the limits in place to continue to help with larger merge requests.

The group also spent some time investigating ways to improve the blocking time for large merge requests and you can see some of the discussion around that here: https://gitlab.com/gitlab-org/gitlab/-/issues/295237.

The last issue I'll drop here is https://gitlab.com/gitlab-org/gitlab/-/issues/241841.

You can also see all of the other issues related to performance that the Code Review group has been working on in GitLab here: https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&utf8...

Thanks again for the feedback - and know that this is something we are looking in to.

Re: Gitlab 13.10 Released

#55

Post by phikai »

diegocg wrote: post #35
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.

The thing I miss the most from the reviewing process is the ability to review diffs per-commit. This is closer to how git is used in the linux mailing lists but gitlab completely breaks that workflow. Github has added some support for that. And yeah, performance sucks, even for trivial patches.

Hi! I'm not sure if you've seen this, but in GitLab 13.0 we released commit based navigation for merge requests. You can read more about this in our docs, but we'd love any feedback you have on the feature.

Documentation: https://docs.gitlab.com/ee/user/project/merge_requests/revie...

Re: Gitlab 13.10 Released

#56

Post by jehlakj »

sytse wrote: post #20
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.

We want to increase both features and usability. It is easier to make something with few features easier to use but we think we can drive both at the same time. For usability we use the System Usability Scale https://about.gitlab.com/handbook/engineering/ux/performance... and increasing it is a target for this quarter "CEO KR: Achieve System Usability (SUS) target of 75. Issue 10314" https://about.gitlab.com/company/…

I’m curious what are some products that successfully do this? I honestly can’t think of any at the top of my head.

To me, more features and ease of usability can’t coexist. There must be compromises. I’ve heard the argument that it’s possible by hiding the advanced features, and I would agree in the short term. But internally, as teams grow and have to maintain multiple documentations noting depreciations, it creeps on the user’s end. It becomes harder to read documentation and there’s also the burden of trying to understand what it’s for because it was something that replaced a previous feature which I don’t have context for.

Please add features responsibly, and stop rewarding new features that seem helpful in a handful of use cases. But who am I kidding here

Re: Gitlab 13.10 Released

#57

Post by phikai »

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.

Re: Gitlab 13.10 Released

#58

Post by sofixa »

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…

Their best shot at competing with GitHub is on features ( and they do a pretty good job at it too), so i think they can't afford to stop shipping new features.

GitHub's UX is simple because it doesn't even come close to what GitLab provides, even in the free tier, and their iteration is much slower. If GitHub had GitLab's features it'd have a complex in some places UX as well.

Re: Gitlab 13.10 Released

#59

Post by sytse »

jehlakj wrote: post #56
sytse wrote: post #20

Earlier quoted context omitted.

We want to increase both features and usability. It is easier to make something with few features easier to use but we think we can drive both at the same time. For usability we use the System Usability Scale https://about.gitlab.com/handbook/engineering/ux/performance... and increasing it is a target for this quarter "CEO KR: Achieve System Usability (SUS) target of 75. Issue 10314" https://about.gitlab.com/company/…

I’m curious what are some products that successfully do this? I honestly can’t think of any at the top of my head. To me, more features and ease of usability can’t coexist. There must be compromises. I’ve heard the argument that it’s possible by hiding the advanced features, and I would agree in the short term. But internally, as teams grow and have to maintain multiple documentations noting depreciations, it creeps…

I'm inspired by products like Zoom, Chrome, VScode, and Slack that are both user friendly and full featured.

Any examples of features that we probably shouldn't have added and should consider removing?

We intent to replace the DIY DevOps toolchain with GitLab. Something that consists of many applications and interfaces. Just having it in a single application would already be a big quality of life improvement for the users. And so far the most common hurdle is being able to match the functionality of the point solutions.

Re: Gitlab 13.10 Released

#60

Post by adduc »

john_cogs wrote: post #43
tyingq wrote: post #8

Earlier quoted context omitted.

It does feel like Gitlab strategically keeps certain things out of the OSS product, like limiting the issues to two states.

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"?

Post reply on HN