8 ms·

I had to use Gitlab several times in the past, mostly because the companies I was working for wanted free private repositories. Though I appreciate to have a G

by KeitIG 9y ago

I had to use Gitlab several times in the past, mostly because the companies I was working for wanted free private repositories. Though I appreciate to have a Github alternative with some really solid CI tools, it just feels like Gitlab cannot compete. Discussions and the UI in general are unreadable, everything feels slow (10 seconds to populate the asignee dropdown, come on...), updates and deployments every two days in the middle of work days ("sorry, I cannot push, Gitlab is down"), and the cringiest thing of all, seeing: "deploying Gitlab CE 10.4.0-rc8" [1]. Releasing Release Candidates?! Maybe I should try to deploy Gitlab on some server of my own. [1] https://twitter.com/gitlabstatus/status/954491741322776582 https://twitter.com/gitlabstatus/status/954491741322776582

foepys 9y ago
Yes, the UI for issues and merge requests is atrocious with its light grey lines on a white background. I cannot skim a issue because I have to really concentrate on where a comment ends a new comment begins. Everything else also seems to float around in empty space, e.g. the emoji reactions. Give me solid black lines for orientation, dammit.
- danpalmer 9y ago
  I've been asking for this for well over a year. Nothing yet. I think they need a fairly fundamental shift in design thinking.
  - svesselov 9y ago
    Hey Dan, Sarrah from the UX team here. I'd love to hear more about your thoughts here. Is there an issue you've created that you can point me to? If not, that's ok. Maybe you can tell me two or three UX changes we could make that you feel would have the most impact on MR and Issues.
    - danpalmer 9y ago
      Hi Sarrah, I raised it with the UX team in a feedback email a while ago. It's not just an issue with merge requests or issues, it's more of a general thing – the colour palette and typography do not make GitLab easy to scan in the same way that GitHub is. I find it requires much more mental overhead to parse GitLab.
      - KeitIG 9y ago
        This, about the mental overhead. So much. @Sarrah: I put some of my thoughts here: https://news.ycombinator.com/item?id=16214892 https://news.ycombinator.com/item?id=16214892
        danpalmer 9y ago
        FWIW I agree with pretty much all of those points. Great to point out things like line length and container size. Also possibly worth mentioning, I have the same problems with much of the marketing site and blog, not just the application.
- svesselov 9y ago
  Thanks for the feedback. I've created this issue for the UX team to discuss ways we can make this better. We agree, there are a lot of opportunities for improvement here. https://gitlab.com/gitlab-org/gitlab-ce/issues/42331 https://gitlab.com/gitlab-org/gitlab-ce/issues/42331
purerandomness 9y ago
I'll bite on the last part about the release candidates: Technically, in software, every stable release originally was the last release candidate in which no showstopper bugs were found. Some decide to put in the extra work and rename that last working release candidate and remove the '-rcX' from the file names.
- lucideer 9y ago
  This may be, but Gitlab seem to push all of their RCs to prod.
  - marinj 9y ago
    I work for GitLab and I was responsible for introducing release changes for this cycle. That is correct, we deploy our RCs to production. I consider RC as only a point in time snapshot of a release that will be sent to public. One thing that is incorrect is that we push all our RCs to production. For example, this release RC1 did not get to GitLab.com because during deployment to our other environments we found an issue that could have caused a large problem at scale. However, we executed a lot of QA and FA tests against all our RCs. You can see this here https://gitlab.com/gitlab-org/release/tasks/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=QA%20task https://gitlab.com/gitlab-org/release/tasks/issues?scope=all... . If we only deployed a final release, we would most likely be overwhelmed with the amount of changes GitLab receives and it would be hard for us to monitor and limit the impact. We are working on getting to continuous deployment to GitLab.com, and as part of this push we started right now with the tools we have at our disposal. One of the ideas to get to stable, non impactful deploys was to create many RCs. Thinking was that if we have a smaller delta between the RCs, we can more effectively check the changes and reduce the overall impact. We also wanted to make sure that we over-communicate our status updates so that we can get feedback in case we overlooked something. Was it problem free? Nope. Did it limit the impact to users? I firmly believe so. We have a lot of work to do to get to blue-green deployments and continuous deployment on GitLab.com scale while we also continue to ship to on premise customers. I do believe that we will get there the best way we know how to, and that is iterating on changes.
dijit 9y ago
What people don't understand about gitlab is that it's a absolutely monumental resource consumer. I run one for a community of hobby developers and to keep my stuff out of github for ideological reasons, but it's running on what is, by _FAR_ the most beefy machine I run. Normally I have machines that are a couple cores, couple gigs of ram, or single purpose machines with under 1G and a dedicated thread on the hypervisor. Gitlab has a 32G DDR3/8 Physical core CPU machine to itself. I consumes, at any given time, about 25% of that (before FS caches, which, you're going to want). I had a friend running this before me on a VPS with 4G of memory and the thing was so annoyingly slow that we blamed the hoster and our users were turning back to bitbucket/github. Since the upgrade, things are smooth as a babies butt. Although it's hard to justify the SERIOUS expense of this server, it's certainly fast enough. I worry about larger deployments though. Btw, you can get a taste for yourself if you like; https://git.drk.sc https://git.drk.sc Maybe it doesn't scale very well with many users/projects. We've only got a couple hundred projects and around 100 users. (and only a handful of CI runners)
- zebra9978 9y ago
  Suggest gitbucket - https://gitbucket.github.io/ https://gitbucket.github.io/ blazingly fast (a single war file - just run "java -jar gitbucket.war" to get started) and has a very nice UI. A plugin system enables you to extend the functionality (including CI) ... and a very active dev community. https://gitbucket.github.io/ https://gitbucket.github.io/
  - pjmlp 9y ago
    Many thanks for the link, as Java/.NET dev it is surely a very good option to know about.
  - carussell 9y ago
    For anyone running this, can you comment? For example, one recurring criticism, before GitLab and the community managed to stamp out the expectation that it would be feasible, was that people were trying to self host a GitLab instance on a cheap SBC (e.g., a Raspberry Pi) or the smallest DigitalOcean plan and were surprised when this wasn't doable, while Gogs and Gitea handle this fine. So to get a general idea of what sort of setup is expected in order to run a gitbucket instance, if you're running one, what are the relevant details?
pizza234 9y ago
> it just feels like Gitlab cannot compete The GitLab hosted service is not really a competitor of GitHub at all; in fact, their (primary) marketing is based on self-hosted service. In my opinion, this has connection to the corporate/engineering culture - GL relies on young and very sharp... but also underpaid minds, at least when compared to GH. I speculate that in order to have a high performing and stable infrastructure, you need grey beards, who require salaries that GL doesn't offer. I highlight speculation - but I'm not surprised when the company losing 6 hours of data is one rather than the other. If this is correct/realistic, it's not a negative judgment; it's just a different orientation.
wodenokoto 9y ago
I use it at work and haven't had anything to complain about, but we are using the self-hosted version.
zhan_eg 9y ago
Using gitlab.com with a group of ~20 devs - one of the main complains some of them had was 'It is slow'. From the last few months I hear more and more 'It is not so slow now, same as github'. So good job on all the performance improvements, users can feel them. So it really depends how long in the past you are talking about :)
- mydigitalself 9y ago
  Thanks, glad you've noticed the improvements. We've still got more to do, but it's been an important part of every release for a while now.
- jdc0589 9y ago
  seconded. I don't know whats been worked on in the past year, but its gotten a lot snappier overall.
jakecodes 9y ago
Jacob from GitLab here. Would love to help you out with your assignee dropdown taking 10 seconds. Currently on GL.com I see it takes 102ms. https://imgur.com/a/vSV21 https://imgur.com/a/vSV21. Also, I am wondering if you were looking at a much older version of GitLab with the discussion and the UI being unreadable. We've made a ton of improvements to our UI in the past year. If you are looking at a recent version, can you tell me what is unreadable about the discussions and the UI in general? That way we can fix it.
- jhasse 9y ago
  > the UI in general? One thing I dislike very much about the UI in general is the fixed/sticky header, which wastes precious vertical space (especially with an Ultra Wide monitor since there's mostly nothing in it). Also due to its color I find it distracting when reading code, would love I could just scroll down to make it go away. Most of the time I'm using the left sidebar, not the top one. For the few times I want to use the top bar, scrolling up really isn't an issue. Note that GitHub also doesn't have this.
- KeitIG 9y ago
  Hello Jacob, glad to see Gitlab employees around! For the assignee dropdowm, it was roughly 6-8 weeks ago. I just went back to an old project and things seem to be much faster now. In the past 3 years, I had to work on Gitlab a few times (for a few months every time), and at the end of every project, I had this feeling of: it was slow (push speed at the time could take 5-10 seconds when it was almost instant on Github), and basically all request were slow (dynamic dropdowns, posting a comment...). It is good to see you are focused on fixing these problems though :) For the UI thing, a few points: - imho, there's just too much on screen. I would say Gitlab is to Github what IntelliJ is to Atom: too much features I don't want to use/see. They just distract me. - the container in the middle is too large, there too many word per line and things get hard to read - Even with the breadcrumb, it is really hard to see "where" I am in the app (which project) - In the issue details page, it is hard to see the continuity of the comments, what is a comment and what is an action ("assignee changed from to..."). I cannot quickly go through an issue an getting on overview of the discussion easily. I think these are mostly tiny UI things to change, and only with some typeography improvements, some borders and better contrasts, things will be a lot more clear. Of course, all of this is highly subjective. 5mn of CSS tweaks: https://imgur.com/a/FLTJT https://imgur.com/a/FLTJT (ofc it adds other issues/concerns, but you get the idea, I am no designer, but sensible to nice UIs)

by KeitIG 9y ago

foepys 9y ago

Yes, the UI for issues and merge requests is atrocious with its light grey lines on a white background. I cannot skim a issue because I have to really concentrate on where a comment ends a new comment begins. Everything else also seems to float around in empty space, e.g. the emoji reactions. Give me solid black lines for orientation, dammit.

danpalmer 9y ago
I've been asking for this for well over a year. Nothing yet. I think they need a fairly fundamental shift in design thinking.
- svesselov 9y ago
  Hey Dan, Sarrah from the UX team here. I'd love to hear more about your thoughts here. Is there an issue you've created that you can point me to? If not, that's ok. Maybe you can tell me two or three UX changes we could make that you feel would have the most impact on MR and Issues.
  - danpalmer 9y ago
    Hi Sarrah, I raised it with the UX team in a feedback email a while ago. It's not just an issue with merge requests or issues, it's more of a general thing – the colour palette and typography do not make GitLab easy to scan in the same way that GitHub is. I find it requires much more mental overhead to parse GitLab.
    - KeitIG 9y ago
      This, about the mental overhead. So much. @Sarrah: I put some of my thoughts here: https://news.ycombinator.com/item?id=16214892 https://news.ycombinator.com/item?id=16214892
      - danpalmer 9y ago
        FWIW I agree with pretty much all of those points. Great to point out things like line length and container size. Also possibly worth mentioning, I have the same problems with much of the marketing site and blog, not just the application.
svesselov 9y ago
Thanks for the feedback. I've created this issue for the UX team to discuss ways we can make this better. We agree, there are a lot of opportunities for improvement here. https://gitlab.com/gitlab-org/gitlab-ce/issues/42331 https://gitlab.com/gitlab-org/gitlab-ce/issues/42331

purerandomness 9y ago

I'll bite on the last part about the release candidates: Technically, in software, every stable release originally was the last release candidate in which no showstopper bugs were found. Some decide to put in the extra work and rename that last working release candidate and remove the '-rcX' from the file names.

lucideer 9y ago
This may be, but Gitlab seem to push all of their RCs to prod.
- marinj 9y ago
  I work for GitLab and I was responsible for introducing release changes for this cycle. That is correct, we deploy our RCs to production. I consider RC as only a point in time snapshot of a release that will be sent to public. One thing that is incorrect is that we push all our RCs to production. For example, this release RC1 did not get to GitLab.com because during deployment to our other environments we found an issue that could have caused a large problem at scale. However, we executed a lot of QA and FA tests against all our RCs. You can see this here https://gitlab.com/gitlab-org/release/tasks/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=QA%20task https://gitlab.com/gitlab-org/release/tasks/issues?scope=all... . If we only deployed a final release, we would most likely be overwhelmed with the amount of changes GitLab receives and it would be hard for us to monitor and limit the impact. We are working on getting to continuous deployment to GitLab.com, and as part of this push we started right now with the tools we have at our disposal. One of the ideas to get to stable, non impactful deploys was to create many RCs. Thinking was that if we have a smaller delta between the RCs, we can more effectively check the changes and reduce the overall impact. We also wanted to make sure that we over-communicate our status updates so that we can get feedback in case we overlooked something. Was it problem free? Nope. Did it limit the impact to users? I firmly believe so. We have a lot of work to do to get to blue-green deployments and continuous deployment on GitLab.com scale while we also continue to ship to on premise customers. I do believe that we will get there the best way we know how to, and that is iterating on changes.

dijit 9y ago

What people don't understand about gitlab is that it's a absolutely monumental resource consumer. I run one for a community of hobby developers and to keep my stuff out of github for ideological reasons, but it's running on what is, by _FAR_ the most beefy machine I run. Normally I have machines that are a couple cores, couple gigs of ram, or single purpose machines with under 1G and a dedicated thread on the hypervisor. Gitlab has a 32G DDR3/8 Physical core CPU machine to itself. I consumes, at any given time, about 25% of that (before FS caches, which, you're going to want). I had a friend running this before me on a VPS with 4G of memory and the thing was so annoyingly slow that we blamed the hoster and our users were turning back to bitbucket/github. Since the upgrade, things are smooth as a babies butt. Although it's hard to justify the SERIOUS expense of this server, it's certainly fast enough. I worry about larger deployments though. Btw, you can get a taste for yourself if you like; https://git.drk.sc https://git.drk.sc Maybe it doesn't scale very well with many users/projects. We've only got a couple hundred projects and around 100 users. (and only a handful of CI runners)

zebra9978 9y ago
Suggest gitbucket - https://gitbucket.github.io/ https://gitbucket.github.io/ blazingly fast (a single war file - just run "java -jar gitbucket.war" to get started) and has a very nice UI. A plugin system enables you to extend the functionality (including CI) ... and a very active dev community. https://gitbucket.github.io/ https://gitbucket.github.io/
- pjmlp 9y ago
  Many thanks for the link, as Java/.NET dev it is surely a very good option to know about.
- carussell 9y ago
  For anyone running this, can you comment? For example, one recurring criticism, before GitLab and the community managed to stamp out the expectation that it would be feasible, was that people were trying to self host a GitLab instance on a cheap SBC (e.g., a Raspberry Pi) or the smallest DigitalOcean plan and were surprised when this wasn't doable, while Gogs and Gitea handle this fine. So to get a general idea of what sort of setup is expected in order to run a gitbucket instance, if you're running one, what are the relevant details?

pizza234 9y ago

> it just feels like Gitlab cannot compete The GitLab hosted service is not really a competitor of GitHub at all; in fact, their (primary) marketing is based on self-hosted service. In my opinion, this has connection to the corporate/engineering culture - GL relies on young and very sharp... but also underpaid minds, at least when compared to GH. I speculate that in order to have a high performing and stable infrastructure, you need grey beards, who require salaries that GL doesn't offer. I highlight speculation - but I'm not surprised when the company losing 6 hours of data is one rather than the other. If this is correct/realistic, it's not a negative judgment; it's just a different orientation.

wodenokoto 9y ago

I use it at work and haven't had anything to complain about, but we are using the self-hosted version.

zhan_eg 9y ago

Using gitlab.com with a group of ~20 devs - one of the main complains some of them had was 'It is slow'. From the last few months I hear more and more 'It is not so slow now, same as github'. So good job on all the performance improvements, users can feel them. So it really depends how long in the past you are talking about :)

mydigitalself 9y ago
Thanks, glad you've noticed the improvements. We've still got more to do, but it's been an important part of every release for a while now.
jdc0589 9y ago
seconded. I don't know whats been worked on in the past year, but its gotten a lot snappier overall.

jakecodes 9y ago

Jacob from GitLab here. Would love to help you out with your assignee dropdown taking 10 seconds. Currently on GL.com I see it takes 102ms. https://imgur.com/a/vSV21 https://imgur.com/a/vSV21. Also, I am wondering if you were looking at a much older version of GitLab with the discussion and the UI being unreadable. We've made a ton of improvements to our UI in the past year. If you are looking at a recent version, can you tell me what is unreadable about the discussions and the UI in general? That way we can fix it.

jhasse 9y ago
> the UI in general? One thing I dislike very much about the UI in general is the fixed/sticky header, which wastes precious vertical space (especially with an Ultra Wide monitor since there's mostly nothing in it). Also due to its color I find it distracting when reading code, would love I could just scroll down to make it go away. Most of the time I'm using the left sidebar, not the top one. For the few times I want to use the top bar, scrolling up really isn't an issue. Note that GitHub also doesn't have this.
KeitIG 9y ago
Hello Jacob, glad to see Gitlab employees around! For the assignee dropdowm, it was roughly 6-8 weeks ago. I just went back to an old project and things seem to be much faster now. In the past 3 years, I had to work on Gitlab a few times (for a few months every time), and at the end of every project, I had this feeling of: it was slow (push speed at the time could take 5-10 seconds when it was almost instant on Github), and basically all request were slow (dynamic dropdowns, posting a comment...). It is good to see you are focused on fixing these problems though :) For the UI thing, a few points: - imho, there's just too much on screen. I would say Gitlab is to Github what IntelliJ is to Atom: too much features I don't want to use/see. They just distract me. - the container in the middle is too large, there too many word per line and things get hard to read - Even with the breadcrumb, it is really hard to see "where" I am in the app (which project) - In the issue details page, it is hard to see the continuity of the comments, what is a comment and what is an action ("assignee changed from to..."). I cannot quickly go through an issue an getting on overview of the discussion easily. I think these are mostly tiny UI things to change, and only with some typeography improvements, some borders and better contrasts, things will be a lot more clear. Of course, all of this is highly subjective. 5mn of CSS tweaks: https://imgur.com/a/FLTJT https://imgur.com/a/FLTJT (ofc it adds other issues/concerns, but you get the idea, I am no designer, but sensible to nice UIs)