Live data from Hacker News

Gitlab 9.0

about.gitlab.com

61–70 of 164 posts

Re: Gitlab 9.0

#61

With the focus on performance, is there any chance we could get pagination on the deploy keys page? Our company is self hosting the CE version and we currently have 339 deployment keys. Every time we need to load the deployment keys page, it takes upwards of 20s. We could probably organize things differently and cut that down, but that would be a significant restructure and time investment for what would essentially…

I've opened an issue, as I couldn't find another. https://gitlab.com/gitlab-org/gitlab-ce/issues/29861

If we have it profiled we can give it the right priority.

Re: Gitlab 9.0

#62
post #36

As much as I love GitLab the UI/UX is still very weak compared to GitHub. And the sidebar change is something in the completely wrong direction. You should also really check out how it looks on a 4k screen.

We also have a new research panel, which includes usability texting. Anyone is welcome to join to provide further feedback, which will significantly impact our product development.

https://about.gitlab.com/researchpanel/

Re: Gitlab 9.0

#64

With the focus on performance, is there any chance we could get pagination on the deploy keys page? Our company is self hosting the CE version and we currently have 339 deployment keys. Every time we need to load the deployment keys page, it takes upwards of 20s. We could probably organize things differently and cut that down, but that would be a significant restructure and time investment for what would essentially…

Pagination on the list of commits in a PR would be awesome also.

Oftentimes a week of work that's bundled in our develop->master RC merge will have more than 100 commits. Gitlab _only_ displays 100, and doesn't let you see the rest; since I like to skim down the commit messages to make release notes for the RC, this is pretty inconvenient.

Re: Gitlab 9.0

#65
post #59

Earlier quoted context omitted.

I'm glad this is a priority for you guys Sid, the one thing keeping me from using Gitlab is that it doesn't feel as snappy as Github. But as a point of reference, I'm also a guy that won't use Atom because it doesn't feel as snappy as Sublime. For some of us, speed comes first.

Is Sublime really an editor of choice if speed comes first?

It's all relative... what kind of computer are you using, the cpu speed, memory available, even OS and drive/ssd can make differences. Even on an i7 with 32gb and an SSD atom was too slow for a really long time... in fact after trying earlier releases of atom and brackets, I almost didn't even try VS Code. I'm really glad I did though.

In any case, it's just a matter of relative performance and perception in relation to what one runs on, and their needs.

Re: Gitlab 9.0

#66
post #4

The performance improvements are very noticeable : general page load times, pushing code to gitlab is as fast as github now and the commit messages load insanely fast, compared to a few months ago where loading commit messages in the UI used to take at least a couple of seconds. I don't follow gitlab development too closely, but they seem to have focused a lot on improving cache performance. But one change that I did…

Thanks for the feedback regarding the sidebar navigation! Here's the issue that we used to chat extensively about it and came to our current design here in 9.0: https://gitlab.com/gitlab-org/gitlab-ce/issues/26200 There's lots of discussion there. We went with a design that leans on getting out of your way and recovers some screen real-estate. We do recognize the one additional click required though. And we are activ…

The application I'm working on, I went with a 3-state navigation... null (default), true (open) or false (closed) ... at large screen sizes null is a soft open, smaller soft closed... toggling goes between the respective hard state and the null/default state. At sm-medium, it's an overlay, at phone/xs it takes over the screen.

I find that this is more intuative to use than a hard on/off only.

Re: Gitlab 9.0

#67

I'm surprised, impressed, and frankly amused in that you can sign into gitlab.com with your github account.

Glad to hear that. You can also import your projects directly (everything will be copied over).

We don't see any reason for you not to do so. GitLab should be the easiest place to get started. If that means logging in with GitHub, we're happy to make that possible.

Re: Gitlab 9.0

#68

With the focus on performance, is there any chance we could get pagination on the deploy keys page? Our company is self hosting the CE version and we currently have 339 deployment keys. Every time we need to load the deployment keys page, it takes upwards of 20s. We could probably organize things differently and cut that down, but that would be a significant restructure and time investment for what would essentially…

I'm afraid it gets a little worse. In an attempt to simplify some of the settings pages, deploy keys were moved onto the repository settings page.

https://gitlab.com/gitlab-org/gitlab-ce/issues/29667

We need to do something about this very soon, so please keep an eye on that issue.

We're going to be doing some more work on settings pages, hopefully in 9.2 and make them a lot better.

https://gitlab.com/gitlab-org/gitlab-ce/issues/28451

Re: Gitlab 9.0

#69
post #59

Earlier quoted context omitted.

I'm glad this is a priority for you guys Sid, the one thing keeping me from using Gitlab is that it doesn't feel as snappy as Github. But as a point of reference, I'm also a guy that won't use Atom because it doesn't feel as snappy as Sublime. For some of us, speed comes first.

Is Sublime really an editor of choice if speed comes first?

Well, compared to Atom, yes. Two somewhat similar tools with trade offs between them, one of them being speed.

Re: Gitlab 9.0

#70

With the focus on performance, is there any chance we could get pagination on the deploy keys page? Our company is self hosting the CE version and we currently have 339 deployment keys. Every time we need to load the deployment keys page, it takes upwards of 20s. We could probably organize things differently and cut that down, but that would be a significant restructure and time investment for what would essentially…

I can't find an issue for this specifically, could you open one so we can get it tracked? https://gitlab.com/gitlab-org/gitlab-ce/issues

The previous suggestions were done on the old suggestion site and I cannot find a link to that site anymore; it's been a while since I have personally brought it up but noticed all the mentions of performance improvements and, combined with our ever-growing list of keys, it felt like something to bring up again.

@zegerjan made a ticket for it, but it's already been closed by Stan because it is being tracked by some general performance ticket. https://gitlab.com/gitlab-org/gitlab-ce/issues/29861

Post reply on HN