8 ms·

GitLab should, frankly, focus on performance/ux/bug-fix releases every other release. And probably for the next 2-3 releases to get some of the warts under cont

GitLab should, frankly, focus on performance/ux/bug-fix releases every other release. And probably for the next 2-3 releases to get some of the warts under control. This constant push for project management features, frankly, is at the expense of the core product. I'd rather use a combination of GitHub and JIRA over Gitlab.

sytse 8y ago
What is the nr. 1 performance/ux/bugfix you would like to see? BTW This month we shipped 35 performance improvements https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name%5B%5D=performance&milestone_title=11.1 https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=... and there were 141 bugs closed in the release of this month https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=11.1&label_name[]=bug https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8...
- omeid2 8y ago
  I have a feeling that many people who constantly ask for "fixes" are the kind of people who want to "fix them all", by rewriting without understanding that it is a never ending cycle. Don't pay attention to them. Just do your thing. Gitlab has provided the much needed competition with real impact (consider Github boards, for example) and you have a company that can pay many people a living. That is more than good enough.
  - sytse 8y ago
    Thank you very much for the encouragement, I appreciate it after significant commenting today while flying from Mexico to San Francisco. You can rest assured we'll keep working on our vision https://about.gitlab.com/direction/product-vision/ https://about.gitlab.com/direction/product-vision/ The people that ask for fixes care about GitLab and are worth listening to. There is an almost infinite demand for new features and we can't make them all (even with more then 2000 open source contributors). But I've found that Hacker News readers have great insights and we'll keep listening and adjusting were we missed the mark. GitLab as a company was born on Hacker News https://news.ycombinator.com/item?id=4428278 https://news.ycombinator.com/item?id=4428278 and although the tone these days feels like different I hope it is a bond for live.
    - Qwertie 8y ago
      I just wanted to add that I have been absolutely loving gitlab. Signed up in 2014 and use it pretty much daily. One of the biggest problems I had was the speed of the web ui but since the great github migration the speed increased massively and has stayed snappy. Contributing code to GitLab has also been my favorite experience with open source as not only were my changes looked at, Gitlab developers actually helped me get things working and write better code.
      - sytse 8y ago
        Thanks so much for commenting, awesome to hear you're loving GitLab. We made a lot of performance improvements, I'm glad you're benefitting from them. On https://about.gitlab.com/handbook/engineering/performance/#past-and-current-performance https://about.gitlab.com/handbook/engineering/performance/#p... you can see what we're measuring. The monitoring of our biggest merge request https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1&var-base=sitespeed_io&var-path=default&var-group=gitlab_com&var-page=_gitlab-org_gitlab-ce_merge_requests_9546&var-browser=chrome&var-connectivity=native&var-function=median&from=now-30d&to=now https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-sum... shows of our fixes regressed and we're looking into what is going wrong. Screenshot for people reading this in the future: https://www.dropbox.com/s/nlriugkzknu2tl9/Screenshot%202018-07-22%2022.15.42.png?dl=0 https://www.dropbox.com/s/nlriugkzknu2tl9/Screenshot%202018-... There is a lot more work to do and we'll keep shipping performance improvements in code and to our infrastructure. The tentative date for our migration to GCP is next weekend. I'm so glad to hear that contributing code to GitLab was a favorite experience! Kudos to our merge request coaches who try to get every merge request over the finish line with a high quality.
        sytse 8y ago
        The migration to GCP is now scheduled for August 11. See https://docs.google.com/document/d/e/2PACX-1vSSnHIgZoKXt_HuTgypvfqzLxh4GMzZ43JK7LrPMtd65M7YCPx1sY4lvj7l27O0Vs7B9KUGj1VFcidq/pub https://docs.google.com/document/d/e/2PACX-1vSSnHIgZoKXt_HuT...
    - 8y ago
  - AFNobody 8y ago
    https://gitlab.com/gitlab-org/gitlab-ce/issues/38066 https://gitlab.com/gitlab-org/gitlab-ce/issues/38066 When glaring security issues sit open for a year, you need to understand GitLab is a problem for anyone who has regular security audits. I am not asking for 100% redirection of resources to fix all the issues. I am suggesting they reprioritize resource allocation to lean more towards fixing issues that exist instead of new feature implementation.
    - omeid2 8y ago
      You want hardened enterprise features, you pay for it; or contribute it, it is open source. I don't understand the attitude of people like you.
      - jmisavage 8y ago
        They have both SaaS and self-hosting options which cost considerable amount of cash ($99/mo per user for the most expensive option) for any large scale deployment. They're earning plenty and they need to fix what is valuable to their customers.
        omeid2 8y ago
        What makes you think they're not listening to their paid customers and fixing their needs? Paid customers get a direct contact.
        AFNobody 8y ago
        It is blocking people from converting to paying customers because as soon as we see an issue like that we know it isn't viable because we'll get denied.
    - teraflop 8y ago
      It's not obvious to me that that's a glaring security issue. If the password were encrypted, then Gitlab would need to be able to decrypt it, so all you're gaining is a bit of security through obscurity. Which doesn't accomplish anything when it's a publicly documented feature of an open source project.
  - woolvalley 8y ago
    Performance is fairly concrete to measure, mostly as part of click responsiveness. https://developers.google.com/web/fundamentals/performance/rail https://developers.google.com/web/fundamentals/performance/r... They can also measure it live in the website, the median response time of API calls and so on. Github has said this: "We’re quite obsessed with performance. We want to make sure the site is always performant and continually fast. For a Rails app, github.com is a really, really quick site and we have a motto that “It’s not shipped until it’s fast.”" https://medium.com/s-c-a-l-e/github-scaling-on-ruby-with-a-nomadic-tech-team-4db562b96dcd https://medium.com/s-c-a-l-e/github-scaling-on-ruby-with-a-n... They can create a performance measurement team, assign tickets based on what they find and prioritize them as part of ticket management. If something is too slow, then maybe it's time to refactor the underlying architecture or subsystem thats making things slow.
- ntenenz 8y ago
  A pretty glaring example is this one (LDAP password stored in plaintext): https://gitlab.com/gitlab-org/gitlab-ce/issues/38066 https://gitlab.com/gitlab-org/gitlab-ce/issues/38066 We purchased a gitlab subscription but cannot obtain infosec approval (and thus cannot use it) due to this issue.
  - sytse 8y ago
    Thanks for mentioning this. I've noted your interest in the relevant issue https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2183#note_89576075 https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2183#not... If you have not done so already please ask our support team if they have an alternative solution. I've heard of people dynamically loading secrets but I'm not sure it addresses your use case.
- rqs 8y ago
  I don't know about the performance and bugfix issues, but based on my experience with gitlab.com, I don't think it has a good UX design. You see, there are many many best practices in the UX world, just like those in the programming world. And seems to me, GitLab is not following many of them. For example, the width of the content area. I've once read an article that trying to dig into that topic, and one opinion that article has brought up was that users eye should not move too far up and down and more importantly left to right. I deeply agreed with this because I found myself feel very tired after reading a width page. The solution is of course to limit how width the content area is, according to many factors (front size for example). Now if you look at the user's home (project list) page on the GitLab, you will found that the page and the list (which is the main content) has been designed to fill 100% width of the view point. On the left side of the list, is the name and description of my projects, and on the right side is the counters + update date. The information on both left and right side are significant, so I may have to scan it from time to time, and it's exhausting. If you're thinking, "Oh it's just the user's home page, no big deal". No No No, the search result page is the same deal, same design language. Now, if you take look GitHub, you will found that they're not only limited the width of their page, they've also limited the width of the project list by adding a sidebar on the page. Which makes me 10 times more comfortable when using it. Also, since we're talking about project list already, let me also remind you that the front is also very important. Currently on the project page, the project name text is bold'ed, and underneath it is the description text. Problem is that the size of both text is the same, which makes them muddled together when doing a quick eye scan. GitHub on the other hand, use white space, front size and color to differentiates those elements which makes their list far better. I did a little re-design to the project list to clarify what I've meant. Before: https://imgur.com/klrah5A https://imgur.com/klrah5A After: https://imgur.com/wcHBVCe https://imgur.com/wcHBVCe And these just two examples, there are many of them. So please GitLab, design your web interface better. I'm currently mainly use your product now and I don't want to have many struggle with it :)
  - jmiserez 8y ago
    There already is an option to set this, at /profile/preferences: Layout width > GitLab can be set up to use different widths depending on your liking. Choose between the fixed (max. 1200px) and the fluid (100%) application layout.
- AFNobody 8y ago
  I am not here to push any specific ticket. I just think GitLab should move in the direction of redirecting more resources to fixing the warts as a general policy decision. Ultimately, I am not your customer and haven't been for a couple years so it is up to you.
- pornel 8y ago
  Treat server responses taking over 100ms as failures and keep fixing that. There isn't 1 thing that's wrong, it's the entire UI, every operation that feels like it has a lag. Using GitLab is like using an app via remote desktop. It's tiring.
- tfha 8y ago
  Merge request page load times. Sometimes it can take like 5s for a merge request page to load (and then another 5s for the comments), and that's noticeably more frustrating than github's snappy UI. 5s isn't world ending but it is obviously slow and frustrating.
kevinykchan 8y ago
I agree. Our team test drove gitlab earlier this year (as in, moving all repos over and using it for a month). We were hoping to consolidate a suite of products into one unified dev hub. )sadly, we found the general clunkyness and slowness a deal breaker for us. Lots of clicks to perform actions, each click requiring a short wait. Many features that applies to single projects don't apply to groups. We felt the core features were still very unfinished, especially when working with multiple repos. We looked at the roadmap and decided to move on.
zaarn 8y ago
You could look at other products too. Gitea has been very close to core Github Features IMO and Gogs (the original fork) has some neat other features separate from Github. There is also Bitbucket which does integrate neatly into JIRA in my experience. There is a lot of choice, Gitlab is great if you need a "everything in one box" solution for every problem or demand you might encounter during development. Other Git-Webapps solve other problems or problem spaces.
- sytse 8y ago
  At GitLab we invested a lot of time on our JIRA integration and we released support for GitLab subgroups in JIRA Development panel yesterday.

sytse 8y ago

What is the nr. 1 performance/ux/bugfix you would like to see? BTW This month we shipped 35 performance improvements https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name%5B%5D=performance&milestone_title=11.1 https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=... and there were 141 bugs closed in the release of this month https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=closed&milestone_title=11.1&label_name[]=bug https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8...

omeid2 8y ago
I have a feeling that many people who constantly ask for "fixes" are the kind of people who want to "fix them all", by rewriting without understanding that it is a never ending cycle. Don't pay attention to them. Just do your thing. Gitlab has provided the much needed competition with real impact (consider Github boards, for example) and you have a company that can pay many people a living. That is more than good enough.
- sytse 8y ago
  Thank you very much for the encouragement, I appreciate it after significant commenting today while flying from Mexico to San Francisco. You can rest assured we'll keep working on our vision https://about.gitlab.com/direction/product-vision/ https://about.gitlab.com/direction/product-vision/ The people that ask for fixes care about GitLab and are worth listening to. There is an almost infinite demand for new features and we can't make them all (even with more then 2000 open source contributors). But I've found that Hacker News readers have great insights and we'll keep listening and adjusting were we missed the mark. GitLab as a company was born on Hacker News https://news.ycombinator.com/item?id=4428278 https://news.ycombinator.com/item?id=4428278 and although the tone these days feels like different I hope it is a bond for live.
  - Qwertie 8y ago
    I just wanted to add that I have been absolutely loving gitlab. Signed up in 2014 and use it pretty much daily. One of the biggest problems I had was the speed of the web ui but since the great github migration the speed increased massively and has stayed snappy. Contributing code to GitLab has also been my favorite experience with open source as not only were my changes looked at, Gitlab developers actually helped me get things working and write better code.
    - sytse 8y ago
      Thanks so much for commenting, awesome to hear you're loving GitLab. We made a lot of performance improvements, I'm glad you're benefitting from them. On https://about.gitlab.com/handbook/engineering/performance/#past-and-current-performance https://about.gitlab.com/handbook/engineering/performance/#p... you can see what we're measuring. The monitoring of our biggest merge request https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1&var-base=sitespeed_io&var-path=default&var-group=gitlab_com&var-page=_gitlab-org_gitlab-ce_merge_requests_9546&var-browser=chrome&var-connectivity=native&var-function=median&from=now-30d&to=now https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-sum... shows of our fixes regressed and we're looking into what is going wrong. Screenshot for people reading this in the future: https://www.dropbox.com/s/nlriugkzknu2tl9/Screenshot%202018-07-22%2022.15.42.png?dl=0 https://www.dropbox.com/s/nlriugkzknu2tl9/Screenshot%202018-... There is a lot more work to do and we'll keep shipping performance improvements in code and to our infrastructure. The tentative date for our migration to GCP is next weekend. I'm so glad to hear that contributing code to GitLab was a favorite experience! Kudos to our merge request coaches who try to get every merge request over the finish line with a high quality.
      - sytse 8y ago
        The migration to GCP is now scheduled for August 11. See https://docs.google.com/document/d/e/2PACX-1vSSnHIgZoKXt_HuTgypvfqzLxh4GMzZ43JK7LrPMtd65M7YCPx1sY4lvj7l27O0Vs7B9KUGj1VFcidq/pub https://docs.google.com/document/d/e/2PACX-1vSSnHIgZoKXt_HuT...
  - 8y ago
- AFNobody 8y ago
  https://gitlab.com/gitlab-org/gitlab-ce/issues/38066 https://gitlab.com/gitlab-org/gitlab-ce/issues/38066 When glaring security issues sit open for a year, you need to understand GitLab is a problem for anyone who has regular security audits. I am not asking for 100% redirection of resources to fix all the issues. I am suggesting they reprioritize resource allocation to lean more towards fixing issues that exist instead of new feature implementation.
  - omeid2 8y ago
    You want hardened enterprise features, you pay for it; or contribute it, it is open source. I don't understand the attitude of people like you.
    - jmisavage 8y ago
      They have both SaaS and self-hosting options which cost considerable amount of cash ($99/mo per user for the most expensive option) for any large scale deployment. They're earning plenty and they need to fix what is valuable to their customers.
      - omeid2 8y ago
        What makes you think they're not listening to their paid customers and fixing their needs? Paid customers get a direct contact.
        AFNobody 8y ago
        It is blocking people from converting to paying customers because as soon as we see an issue like that we know it isn't viable because we'll get denied.
  - teraflop 8y ago
    It's not obvious to me that that's a glaring security issue. If the password were encrypted, then Gitlab would need to be able to decrypt it, so all you're gaining is a bit of security through obscurity. Which doesn't accomplish anything when it's a publicly documented feature of an open source project.
- woolvalley 8y ago
  Performance is fairly concrete to measure, mostly as part of click responsiveness. https://developers.google.com/web/fundamentals/performance/rail https://developers.google.com/web/fundamentals/performance/r... They can also measure it live in the website, the median response time of API calls and so on. Github has said this: "We’re quite obsessed with performance. We want to make sure the site is always performant and continually fast. For a Rails app, github.com is a really, really quick site and we have a motto that “It’s not shipped until it’s fast.”" https://medium.com/s-c-a-l-e/github-scaling-on-ruby-with-a-nomadic-tech-team-4db562b96dcd https://medium.com/s-c-a-l-e/github-scaling-on-ruby-with-a-n... They can create a performance measurement team, assign tickets based on what they find and prioritize them as part of ticket management. If something is too slow, then maybe it's time to refactor the underlying architecture or subsystem thats making things slow.
ntenenz 8y ago
A pretty glaring example is this one (LDAP password stored in plaintext): https://gitlab.com/gitlab-org/gitlab-ce/issues/38066 https://gitlab.com/gitlab-org/gitlab-ce/issues/38066 We purchased a gitlab subscription but cannot obtain infosec approval (and thus cannot use it) due to this issue.
- sytse 8y ago
  Thanks for mentioning this. I've noted your interest in the relevant issue https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2183#note_89576075 https://gitlab.com/gitlab-org/omnibus-gitlab/issues/2183#not... If you have not done so already please ask our support team if they have an alternative solution. I've heard of people dynamically loading secrets but I'm not sure it addresses your use case.
rqs 8y ago
I don't know about the performance and bugfix issues, but based on my experience with gitlab.com, I don't think it has a good UX design. You see, there are many many best practices in the UX world, just like those in the programming world. And seems to me, GitLab is not following many of them. For example, the width of the content area. I've once read an article that trying to dig into that topic, and one opinion that article has brought up was that users eye should not move too far up and down and more importantly left to right. I deeply agreed with this because I found myself feel very tired after reading a width page. The solution is of course to limit how width the content area is, according to many factors (front size for example). Now if you look at the user's home (project list) page on the GitLab, you will found that the page and the list (which is the main content) has been designed to fill 100% width of the view point. On the left side of the list, is the name and description of my projects, and on the right side is the counters + update date. The information on both left and right side are significant, so I may have to scan it from time to time, and it's exhausting. If you're thinking, "Oh it's just the user's home page, no big deal". No No No, the search result page is the same deal, same design language. Now, if you take look GitHub, you will found that they're not only limited the width of their page, they've also limited the width of the project list by adding a sidebar on the page. Which makes me 10 times more comfortable when using it. Also, since we're talking about project list already, let me also remind you that the front is also very important. Currently on the project page, the project name text is bold'ed, and underneath it is the description text. Problem is that the size of both text is the same, which makes them muddled together when doing a quick eye scan. GitHub on the other hand, use white space, front size and color to differentiates those elements which makes their list far better. I did a little re-design to the project list to clarify what I've meant. Before: https://imgur.com/klrah5A https://imgur.com/klrah5A After: https://imgur.com/wcHBVCe https://imgur.com/wcHBVCe And these just two examples, there are many of them. So please GitLab, design your web interface better. I'm currently mainly use your product now and I don't want to have many struggle with it :)
- jmiserez 8y ago
  There already is an option to set this, at /profile/preferences: Layout width > GitLab can be set up to use different widths depending on your liking. Choose between the fixed (max. 1200px) and the fluid (100%) application layout.
AFNobody 8y ago
I am not here to push any specific ticket. I just think GitLab should move in the direction of redirecting more resources to fixing the warts as a general policy decision. Ultimately, I am not your customer and haven't been for a couple years so it is up to you.
pornel 8y ago
Treat server responses taking over 100ms as failures and keep fixing that. There isn't 1 thing that's wrong, it's the entire UI, every operation that feels like it has a lag. Using GitLab is like using an app via remote desktop. It's tiring.
tfha 8y ago
Merge request page load times. Sometimes it can take like 5s for a merge request page to load (and then another 5s for the comments), and that's noticeably more frustrating than github's snappy UI. 5s isn't world ending but it is obviously slow and frustrating.

kevinykchan 8y ago

I agree. Our team test drove gitlab earlier this year (as in, moving all repos over and using it for a month). We were hoping to consolidate a suite of products into one unified dev hub. )sadly, we found the general clunkyness and slowness a deal breaker for us. Lots of clicks to perform actions, each click requiring a short wait. Many features that applies to single projects don't apply to groups. We felt the core features were still very unfinished, especially when working with multiple repos. We looked at the roadmap and decided to move on.

zaarn 8y ago

You could look at other products too. Gitea has been very close to core Github Features IMO and Gogs (the original fork) has some neat other features separate from Github. There is also Bitbucket which does integrate neatly into JIRA in my experience. There is a lot of choice, Gitlab is great if you need a "everything in one box" solution for every problem or demand you might encounter during development. Other Git-Webapps solve other problems or problem spaces.

sytse 8y ago
At GitLab we invested a lot of time on our JIRA integration and we released support for GitLab subgroups in JIRA Development panel yesterday.