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

Gitlab 9.0

about.gitlab.com

Post reply on HN
Print view View original

41–50 of 164 posts

Re: Gitlab 9.0

#41

Post by superplussed »

sytse wrote: post #6
ploggingdev wrote: post #3

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…

Great to hear you notice the performance improvements. We're very happy with the improvements but we still have long way to go. We want the 99% latency under 1s and right now it is 2s: https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk... There are some controller timings that are red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV... And the git access timings are a sea of red https://drive.go…

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.

Re: Gitlab 9.0

#42

Post by bryanlarsen »

microcolonel wrote: post #38
danial wrote: post #35

Congratulations on shipping 9.0. It's great to see a lot of improvements. Being able to reorder issues in the board is a welcome change. The subgroups is an interesting feature. I look forward to playing with it more. I am still waiting on the ability to view issues on a board across a group (or now, a subgroup). Since Gitlab projects are repo-centric, I have hard time tracking issues across many repositories in a si…

Not that this is a solution everywhere, but I'm always telling people that single-repo is the way to go for an integrated team. My rule is that if your business unit can reasonably control a codebase, and you have access to it, it should be in the same repo as your other codebases, full-stop. I've seen too many npm messes where people obsess over putting every button, dropdown, heading, and dumb image component in it…

Yup, I think Google & Facebook have this one right, a mono-repo is the way to go.

But there are advantages to multi-repos, especially if you're trying to share with clients and/or open source. You can have your cake and eat it too: we use https://github.com/splitsh/lite to update our micro-repos on every commit to our monorepo.

Re: Gitlab 9.0

#43

Post by sytse »

superplussed wrote: post #41
sytse wrote: post #6

Earlier quoted context omitted.

Great to hear you notice the performance improvements. We're very happy with the improvements but we still have long way to go. We want the 99% latency under 1s and right now it is 2s: https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk... There are some controller timings that are red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV... And the git access timings are a sea of red https://drive.go…

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.

Speed is essential for a tool like GitLab that people use intensely. We've made great progress in having better monitoring to see what the cause is. For 9.1 we've scheduled many more performance improvements https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf... than we were able to complete in 9.0 https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

Re: Gitlab 9.0

#44

Post by GordonS »

nik736 wrote: 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.

Well, IMO the Github UI has been taking some steps backwards recently. If Gitlab keeps improving and Github worsening, they'll be at parity before too long

Re: Gitlab 9.0

#45

Post by victorwu »

danial wrote: post #35

Congratulations on shipping 9.0. It's great to see a lot of improvements. Being able to reorder issues in the board is a welcome change. The subgroups is an interesting feature. I look forward to playing with it more. I am still waiting on the ability to view issues on a board across a group (or now, a subgroup). Since Gitlab projects are repo-centric, I have hard time tracking issues across many repositories in a si…

Like Job mentioned, we've been ramping up issue boards and groups (subgroups now) rapidly in the past few releases. Group-level issue boards are definitely on our radar. Feel free to leave any comments on the issue itself that Job linked: https://gitlab.com/gitlab-org/gitlab-ee/issues/928.

Currently we are considering bringing all the issues of all projects (that are in the same group) into one location, i.e the group-level board, exactly as you describe it.

Team-first/team-based collaboration is something we are now highly interested in, with subgroups being a big feature in 9.0 in this direction. Our next step will be to tie that with issue boards. Thanks for the feedback!

Re: Gitlab 9.0

#46

Post by ykler »

frikk wrote: post #19
tomc1985 wrote: post #8

Gitlab was really promising for my colleagues and I, but its inability to host git repos on the url root (aka gitrepo.mycompany.com/product.git) without hacking means its a no-go as we're not particularly inclined to redo all our development, deployment, and testing infrastructure. We use git a lot in our organization, including customer-facing stuff, so it would be a large transition. Also stubborn coworkers who don…

What if you just set up an nginx reverse proxy? gitrepo.mycompany.com/product.git --> reverse proxy to git.mycompany.com/gitrepo/product.git Should be straight forward in nginx

Just curious since I am not experienced with this stuff, are you talking about a TCP reverse proxy (so it could work with the SSH protocol too)? And would haproxy work equally well to nginx for this?

Re: Gitlab 9.0

#48

Post by MartinCron »

GordonS wrote: post #44
nik736 wrote: 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.

Well, IMO the Github UI has been taking some steps backwards recently. If Gitlab keeps improving and Github worsening, they'll be at parity before too long

That's not the way to reach parity!

Re: Gitlab 9.0

#49

Post by sytse »

GordonS wrote: post #44
nik736 wrote: 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.

Well, IMO the Github UI has been taking some steps backwards recently. If Gitlab keeps improving and Github worsening, they'll be at parity before too long

We certainly don't want to win in a race to the bottom.

To get an idea what our UX team is working on please see their update from this Monday:

Video https://www.youtube.com/watch?v=TMdw-plNfDQ

Slides https://docs.google.com/presentation/d/1LM6wHxGVRwHwQvGJiXwF...

Re: Gitlab 9.0

#50

Post by victorwu »

microcolonel wrote: post #38
danial wrote: post #35

Congratulations on shipping 9.0. It's great to see a lot of improvements. Being able to reorder issues in the board is a welcome change. The subgroups is an interesting feature. I look forward to playing with it more. I am still waiting on the ability to view issues on a board across a group (or now, a subgroup). Since Gitlab projects are repo-centric, I have hard time tracking issues across many repositories in a si…

Not that this is a solution everywhere, but I'm always telling people that single-repo is the way to go for an integrated team. My rule is that if your business unit can reasonably control a codebase, and you have access to it, it should be in the same repo as your other codebases, full-stop. I've seen too many npm messes where people obsess over putting every button, dropdown, heading, and dumb image component in it…

We originally built GitLab with that use case of a single repo in mind. Create a GitLab project, and you have a single repository for code. We know this is an important use case for many teams, because of it's straightforward, simple scenario. It's something that's important to us, even as we expand to other use cases of multi-repo teams (groups/subgroups housing of projects). Thanks for the comment.
Post reply on HN