5 ms·

I was sucked in by Gitlab's feature list and marketing. But holy shit so many things are half assed and so many features are buggy and broken. Like their wikis

I was sucked in by Gitlab's feature list and marketing. But holy shit so many things are half assed and so many features are buggy and broken. Like their wikis would sometimes just straight up delete text and their webhooks would break images. I started a bunch of issues but they really have no chance of getting fixed anytime soon. Just shows how different your impression of something is after actually using it.

sytse 7y ago
The wiki is GitLab should not delete text, please file a bug if you had dataloss. The current state of the wiki isn't great but we're also not seeing a lot of people care about it. Many people are switching to static websites. Therefore we're not investing to get the wiki better than the current state of a half circle. BTW We've recently measured experience baselines in GitLab and we agree we still have a lot of work to do https://about.gitlab.com/2019/09/05/refining-gitlab-product-experience/ https://about.gitlab.com/2019/09/05/refining-gitlab-product-...
- antonvs 7y ago
  > The current state of the wiki isn't great but we're also not seeing a lot of people care about it. That may be because people who do care use a different product. Be careful you don't metric your way to extinction.
- mikepurvis 7y ago
  Perhaps an argument for focusing on doing a few things well? I work for a GitLab shop, but we don't use the bugtracker (Jira) or wiki (Confluence), we mostly don't use the CI (Jenkins is just more flexible), and we definitely don't use the container stuff. We currently do use the review workflow but at various points have considered moving to a different tool for that as well. So yeah, we would have been fine with a GitLab that did less— a lot less, and instead prioritized supplying first class integration points and supported plugins for other best-in-class tools.
  - pritianka 7y ago
    Hi there! Just wanted to add my two cents here. Just like you choose to use SCM and workflow review, we have a lot of other users and customers utilizing different permutations and combinations of the various stages. Over time, various stages all move toward maturity, some faster than others. I know this is a different model than most software companies and it has its downsides. But the net positive is that we are able to provide an increasingly unified experience for DevOps. Note that at other companies the same thing happens except they market different stages as separate "products". They gain on the marketing but lose on the ultimate user benefit (again, IMHO).
    - Scarbutt 7y ago
      But the net positive is that we are able to provide an increasingly unified experience for DevOps. The point of the GP and others where that as of now there is nothing positive about the "unified experience for DevOps", it is very buggy and lacking, maybe someday.
    - ulrikrasmussen 7y ago
      I would much rather have fewer features which work well. For example, until recently there was a restriction that jobs could only run in parallel if they were defined in the same "stage", and no two stages could have running jobs at the same time. This means that a job whose dependencies were met could not necessarily be started because it belonged to a later stage (and jobs cannot depend on other jobs from its own stage, more on that later). GitLab then introduced another way of specifying dependencies using the keyword "needs" ("dependencies" was already taken by the half-baked implementation). This allows jobs from multiple stages to run concurrently, as you would expect. However, you are still required to shoehorn your jobs into stages, even though they should be completely deprecated by now. Worse, the restriction that jobs cannot depend on other jobs from the same stage still remains. On top of that, the visualization of a pipeline pretends that the new way of specifying dependencies does not exist, so all the arrows between the jobs are meaningless. I would much rather have had a proper implementation of the simple, more general approach, than having to deal with the legacy of a hacky and half-baked solution.
- jrochkind1 7y ago
  I'd rather have no (eg) wiki feature at all then have a half-assed one. Because _if_ I feel like the feature might be useful, I'm going to try to use it, and invest time in trying to use it, and only then find that it's not reliable or well-polished after all. The more such features there are, the more chance I'll spend at least some time being frustrated by at least one of them. One of the joys of really well-polished software is that if the feature wasn't worth doing right (and not every feature is!), it simply isn't there at all, so if a feature is there I can count on it being well-thought-out and well-executed.
- KaoruAoiShiho 7y ago
  A wiki's not the same usecase as static site, a static site is for marketing and wikis are for project management. I mean maybe people would use it if it weren't crappy? I would've been happier if the wiki didn't exist and I didn't invest time into wrangling it. ATM it's just a frustration. It's not dataloss but it deletes text in the same line as wiki internal links. And what kind of wiki doesn't use lots of internal links. https://gitlab.com/gitlab-org/gitlab-ce/issues/67132 https://gitlab.com/gitlab-org/gitlab-ce/issues/67132 This basically makes the wiki unusable but it's marked as "backlog". If you really do feel this way about the wiki then it should be clearly marked in your marketing. I read about your "integrated devops experience" and was onboard, but if your intent is as you say then you need to put parentheses next to the wiki feature item list that says "this is crap and we intend for it to stay crap" and we'll know to value it appropriately when choosing a provider.
  - sytse 7y ago
    I looked up our wiki direction and the ideas is to allow WYSIWYG collaboration, see https://about.gitlab.com/direction/create/wiki/ https://about.gitlab.com/direction/create/wiki/ I'm surprised that this wiki bug that two people here mention has only one upvote https://gitlab.com/gitlab-org/gitlab-ce/issues/48641 https://gitlab.com/gitlab-org/gitlab-ce/issues/48641 I'm not sure if the complaints are over multiple issues, if the wiki doesn't get a lot of usage, or something else is going on. The bug sounds legitimate.
  - phikai 7y ago
    > A wiki's not the same usecase as static site, a static site is for marketing and wikis are for project management. I mean maybe people would use it if it weren't crappy? I would've been happier if the wiki didn't exist and I didn't invest time into wrangling it. ATM it's just a frustration. Hi! I'm the current PM for our wiki's and I agree that the experience isn't up to par at the moment. As Sid mentioned, historically wiki's were not a priority as many users weren't coming to GitLab for those features. We're starting to see shifts in that thinking as we've penetrated deeper in to some markets so we're working to adjust accordingly. > It's not dataloss but it deletes text in the same line as wiki internal links. And what kind of wiki doesn't use lots of internal links. https://gitlab.com/gitlab-org/gitlab-ce/issues/67132 https://gitlab.com/gitlab-org/gitlab-ce/issues/67132 This basically makes the wiki unusable but it's marked as "backlog". That issue is interesting because it's a link mechanism that relies on the underlying wiki project that we use. (i.e. that's no common markdown syntax). Discoverability of things like that is limited to some power users who know that we're using Gollum underneath and know of some of the supported syntax. What we've seen is that most users don't use that functionality and instead just use absolute links in markdown. This likely explains why the upvotes are so low on the bug report as well. For comparison, we've seen more demand to support linking to projects: https://gitlab.com/gitlab-org/gitlab-ce/issues/20726 https://gitlab.com/gitlab-org/gitlab-ce/issues/20726, than within the wiki itself. As an FYI, I've also asked a couple of our engineers to take a look at that specific issue to see if it's something that can be relatively easy to fix. No guarantees on anything here, but we'll try to get a bit more relevant engineering information to assist in understanding scope. > If you really do feel this way about the wiki then it should be clearly marked in your marketing. That's a lot of what our maturity pages are trying to do. We're being honest with ourselves and with our users about where we think the functionality of certain features are. In fact, when I started we had the Wiki listed at a `Complete` maturity which I reduced to viable: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/23525 https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/... If you take a look at the wiki strategy (https://about.gitlab.com/direction/create/wiki/ https://about.gitlab.com/direction/create/wiki/) our next focus is going to be on making editing easier and improving navigation. We think these things will start to move the conversation forward for users and we'll see more adoption. Even more, if you think we're not moving in the right direction with the Wiki's please be vocal on the issue tracker, or open an issue for the Wiki Strategy or even a merge request to change something. We're happy to have the feedback, and don't hesitate to tag me on wiki issues I'm @phikai on GitLab as well.
ori_b 7y ago
I don't really use gitlab, but I wrote my own git implementation recently (https://github.com/oridb/git9 https://github.com/oridb/git9), and I've had bug reports when people tried to use it on gitlab. Apparently it can deadlock processes on the server, stopping the clone -- and they never get cleaned up. While they don't prevent anyone else from using the machine, they do sit around wasting resources, and potentially causing a denial of service attack. I figured out bugs for github's issues, but I haven't been able to find one for gitlab's, and they've been pretty silent on the bug that someone else filed about this as far as I can tell. It didn't feel like a particularly easy to trace system when I tried debugging.
- ori_b 7y ago
  ("figured out bugs" should read as "figured out workarounds")
- meks 7y ago
  > they've been pretty silent on the bug that someone else filed about this Hi ori_b, do you have a link to an issue for this? Happy to bring this up to the team for prioritization.
enraged_camel 7y ago
My impression is the opposite. Compared to Github, Gitlab is simply phenomenal, especially the UX. It's honestly one of the few pieces of software that I truly enjoy using every day.
- rossmohax 7y ago
  Enabling "AutoDevops" on ALL existing projects and wasting runner minutes people payed for is indeed "phenomenal".
  - Narty 7y ago
    Turn is off then? https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#auto-devops-core-only https://docs.gitlab.com/ee/user/admin_area/settings/continuo...
    - rossmohax 7y ago
      You can't access admin area on gitlab.com. Besides, if you manage to find their issue you'd see carnage this decision caused for some of the customers. Even those with own runners found them swamped in jobs doomed to fail , blocking actually inportant pipelines. Autodevops as a product feature targets very niche audience of teams running gitlab, but without dedicated DevOps team , it is by definition a very opinionated view on CI/CD and I can not see how it was acceptable to suddenly enable it on all existing projects on whole gitlab.com overnight.
      - dgruesso 7y ago
        GitLab PM here. As part of 11.10, we introduced the ability to disable Auto DevOps at the group-level (https://docs.gitlab.com/ee/topics/autodevops/#at-the-group-level https://docs.gitlab.com/ee/topics/autodevops/#at-the-group-l...). This will disable it for all projects under the particular group. We are working to make Auto DevOps smarter and only run in cases where it can add value (https://gitlab.com/gitlab-org/gitlab-ce/issues/57483 https://gitlab.com/gitlab-org/gitlab-ce/issues/57483). I agree with you, we don't currently cover all the use cases we'd like to, but we're working to expand the feature set and technologies we cover. If you had a particular use case that was not well covered, I'd love to learn more about it so we can evaluate related improvements. You can reach me at daniel at gitlab dot com. Thanks.
waltera 7y ago
We had a very similar experience with Gitlab too. Our teams evaluated Gitlab for a year before completely migrating away from it (to Github Enterprise for SCM, Confluence for wiki, YouTrack for issues and TeamCity for CI). Not a single team (out of 20) was happy with the overall performance (and especially the performance of code search). As far as wiki is concerned, Confluence's UI has its own share of issues, even after their recent overhaul, but all in all it is much better product. YouTrack and TeamCity are simply much more polished & stable products and are (in our experience) easier to administer than the competing offerings from Gitlab.
- sytse 7y ago
  Code search is not good at GitLab.com at the moment. We're working to enable ElasticSearch for GitLab.com to improve the situation https://about.gitlab.com/2019/03/20/enabling-global-search-elasticsearch-gitlab-com/ https://about.gitlab.com/2019/03/20/enabling-global-search-e...
- phikai 7y ago
  > Not a single team (out of 20) was happy with the overall performance (and especially the performance of code search). Hi! I'm the current PM for our search and as Sid mentioned we've steadily been working to improve that. It's been getting a lot better, but most of the improvements are heavily reliant on also having Elasticsearch enabled. Without that, there's really no way for us to provide a optimal search experience for the amount of data and content there. If you have any specific search feedback, please feel free to open an issue or reach out to me @phikai on GitLab.
milofeynman 7y ago
They love producing public facing verbose process documents... At first I thought, oh these are some neat ideas, but the more that they produce, the more I wonder how they get anything done with so much (verbose) process.
- williamchia 7y ago
  I work at GitLab and can shed some light here. As a 100% remote company we work in all timezone. Writing things down actually helps make things more efficient. At my last job, to get anything done I needed to call a meeting because state lived in people's heads. When someone left, of if you couldn't get them to a meeting, it was very painful. It took forever to get things done because you needed to physically be present in order to work. At GitLab because so much is documented it's easy to pick up state and collaborate with co-workers in all timezones. What's cool, is because it's public, other random people will jump in and help you out that you'd never expect since they have access to everything you have.
waylandsmithers 7y ago
I don't use Gitlab but still appreciate what they are trying to do. I think it's good to have competition and options in this space.

sytse 7y ago

The wiki is GitLab should not delete text, please file a bug if you had dataloss. The current state of the wiki isn't great but we're also not seeing a lot of people care about it. Many people are switching to static websites. Therefore we're not investing to get the wiki better than the current state of a half circle. BTW We've recently measured experience baselines in GitLab and we agree we still have a lot of work to do https://about.gitlab.com/2019/09/05/refining-gitlab-product-experience/ https://about.gitlab.com/2019/09/05/refining-gitlab-product-...

antonvs 7y ago
> The current state of the wiki isn't great but we're also not seeing a lot of people care about it. That may be because people who do care use a different product. Be careful you don't metric your way to extinction.
mikepurvis 7y ago
Perhaps an argument for focusing on doing a few things well? I work for a GitLab shop, but we don't use the bugtracker (Jira) or wiki (Confluence), we mostly don't use the CI (Jenkins is just more flexible), and we definitely don't use the container stuff. We currently do use the review workflow but at various points have considered moving to a different tool for that as well. So yeah, we would have been fine with a GitLab that did less— a lot less, and instead prioritized supplying first class integration points and supported plugins for other best-in-class tools.
- pritianka 7y ago
  Hi there! Just wanted to add my two cents here. Just like you choose to use SCM and workflow review, we have a lot of other users and customers utilizing different permutations and combinations of the various stages. Over time, various stages all move toward maturity, some faster than others. I know this is a different model than most software companies and it has its downsides. But the net positive is that we are able to provide an increasingly unified experience for DevOps. Note that at other companies the same thing happens except they market different stages as separate "products". They gain on the marketing but lose on the ultimate user benefit (again, IMHO).
  - Scarbutt 7y ago
    But the net positive is that we are able to provide an increasingly unified experience for DevOps. The point of the GP and others where that as of now there is nothing positive about the "unified experience for DevOps", it is very buggy and lacking, maybe someday.
  - ulrikrasmussen 7y ago
    I would much rather have fewer features which work well. For example, until recently there was a restriction that jobs could only run in parallel if they were defined in the same "stage", and no two stages could have running jobs at the same time. This means that a job whose dependencies were met could not necessarily be started because it belonged to a later stage (and jobs cannot depend on other jobs from its own stage, more on that later). GitLab then introduced another way of specifying dependencies using the keyword "needs" ("dependencies" was already taken by the half-baked implementation). This allows jobs from multiple stages to run concurrently, as you would expect. However, you are still required to shoehorn your jobs into stages, even though they should be completely deprecated by now. Worse, the restriction that jobs cannot depend on other jobs from the same stage still remains. On top of that, the visualization of a pipeline pretends that the new way of specifying dependencies does not exist, so all the arrows between the jobs are meaningless. I would much rather have had a proper implementation of the simple, more general approach, than having to deal with the legacy of a hacky and half-baked solution.
jrochkind1 7y ago
I'd rather have no (eg) wiki feature at all then have a half-assed one. Because _if_ I feel like the feature might be useful, I'm going to try to use it, and invest time in trying to use it, and only then find that it's not reliable or well-polished after all. The more such features there are, the more chance I'll spend at least some time being frustrated by at least one of them. One of the joys of really well-polished software is that if the feature wasn't worth doing right (and not every feature is!), it simply isn't there at all, so if a feature is there I can count on it being well-thought-out and well-executed.
KaoruAoiShiho 7y ago
A wiki's not the same usecase as static site, a static site is for marketing and wikis are for project management. I mean maybe people would use it if it weren't crappy? I would've been happier if the wiki didn't exist and I didn't invest time into wrangling it. ATM it's just a frustration. It's not dataloss but it deletes text in the same line as wiki internal links. And what kind of wiki doesn't use lots of internal links. https://gitlab.com/gitlab-org/gitlab-ce/issues/67132 https://gitlab.com/gitlab-org/gitlab-ce/issues/67132 This basically makes the wiki unusable but it's marked as "backlog". If you really do feel this way about the wiki then it should be clearly marked in your marketing. I read about your "integrated devops experience" and was onboard, but if your intent is as you say then you need to put parentheses next to the wiki feature item list that says "this is crap and we intend for it to stay crap" and we'll know to value it appropriately when choosing a provider.
- sytse 7y ago
  I looked up our wiki direction and the ideas is to allow WYSIWYG collaboration, see https://about.gitlab.com/direction/create/wiki/ https://about.gitlab.com/direction/create/wiki/ I'm surprised that this wiki bug that two people here mention has only one upvote https://gitlab.com/gitlab-org/gitlab-ce/issues/48641 https://gitlab.com/gitlab-org/gitlab-ce/issues/48641 I'm not sure if the complaints are over multiple issues, if the wiki doesn't get a lot of usage, or something else is going on. The bug sounds legitimate.
- phikai 7y ago
  > A wiki's not the same usecase as static site, a static site is for marketing and wikis are for project management. I mean maybe people would use it if it weren't crappy? I would've been happier if the wiki didn't exist and I didn't invest time into wrangling it. ATM it's just a frustration. Hi! I'm the current PM for our wiki's and I agree that the experience isn't up to par at the moment. As Sid mentioned, historically wiki's were not a priority as many users weren't coming to GitLab for those features. We're starting to see shifts in that thinking as we've penetrated deeper in to some markets so we're working to adjust accordingly. > It's not dataloss but it deletes text in the same line as wiki internal links. And what kind of wiki doesn't use lots of internal links. https://gitlab.com/gitlab-org/gitlab-ce/issues/67132 https://gitlab.com/gitlab-org/gitlab-ce/issues/67132 This basically makes the wiki unusable but it's marked as "backlog". That issue is interesting because it's a link mechanism that relies on the underlying wiki project that we use. (i.e. that's no common markdown syntax). Discoverability of things like that is limited to some power users who know that we're using Gollum underneath and know of some of the supported syntax. What we've seen is that most users don't use that functionality and instead just use absolute links in markdown. This likely explains why the upvotes are so low on the bug report as well. For comparison, we've seen more demand to support linking to projects: https://gitlab.com/gitlab-org/gitlab-ce/issues/20726 https://gitlab.com/gitlab-org/gitlab-ce/issues/20726, than within the wiki itself. As an FYI, I've also asked a couple of our engineers to take a look at that specific issue to see if it's something that can be relatively easy to fix. No guarantees on anything here, but we'll try to get a bit more relevant engineering information to assist in understanding scope. > If you really do feel this way about the wiki then it should be clearly marked in your marketing. That's a lot of what our maturity pages are trying to do. We're being honest with ourselves and with our users about where we think the functionality of certain features are. In fact, when I started we had the Wiki listed at a `Complete` maturity which I reduced to viable: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/23525 https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/... If you take a look at the wiki strategy (https://about.gitlab.com/direction/create/wiki/ https://about.gitlab.com/direction/create/wiki/) our next focus is going to be on making editing easier and improving navigation. We think these things will start to move the conversation forward for users and we'll see more adoption. Even more, if you think we're not moving in the right direction with the Wiki's please be vocal on the issue tracker, or open an issue for the Wiki Strategy or even a merge request to change something. We're happy to have the feedback, and don't hesitate to tag me on wiki issues I'm @phikai on GitLab as well.

ori_b 7y ago

I don't really use gitlab, but I wrote my own git implementation recently (https://github.com/oridb/git9 https://github.com/oridb/git9), and I've had bug reports when people tried to use it on gitlab. Apparently it can deadlock processes on the server, stopping the clone -- and they never get cleaned up. While they don't prevent anyone else from using the machine, they do sit around wasting resources, and potentially causing a denial of service attack. I figured out bugs for github's issues, but I haven't been able to find one for gitlab's, and they've been pretty silent on the bug that someone else filed about this as far as I can tell. It didn't feel like a particularly easy to trace system when I tried debugging.

ori_b 7y ago
("figured out bugs" should read as "figured out workarounds")
meks 7y ago
> they've been pretty silent on the bug that someone else filed about this Hi ori_b, do you have a link to an issue for this? Happy to bring this up to the team for prioritization.

enraged_camel 7y ago

My impression is the opposite. Compared to Github, Gitlab is simply phenomenal, especially the UX. It's honestly one of the few pieces of software that I truly enjoy using every day.

rossmohax 7y ago
Enabling "AutoDevops" on ALL existing projects and wasting runner minutes people payed for is indeed "phenomenal".
- Narty 7y ago
  Turn is off then? https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#auto-devops-core-only https://docs.gitlab.com/ee/user/admin_area/settings/continuo...
  - rossmohax 7y ago
    You can't access admin area on gitlab.com. Besides, if you manage to find their issue you'd see carnage this decision caused for some of the customers. Even those with own runners found them swamped in jobs doomed to fail , blocking actually inportant pipelines. Autodevops as a product feature targets very niche audience of teams running gitlab, but without dedicated DevOps team , it is by definition a very opinionated view on CI/CD and I can not see how it was acceptable to suddenly enable it on all existing projects on whole gitlab.com overnight.
    - dgruesso 7y ago
      GitLab PM here. As part of 11.10, we introduced the ability to disable Auto DevOps at the group-level (https://docs.gitlab.com/ee/topics/autodevops/#at-the-group-level https://docs.gitlab.com/ee/topics/autodevops/#at-the-group-l...). This will disable it for all projects under the particular group. We are working to make Auto DevOps smarter and only run in cases where it can add value (https://gitlab.com/gitlab-org/gitlab-ce/issues/57483 https://gitlab.com/gitlab-org/gitlab-ce/issues/57483). I agree with you, we don't currently cover all the use cases we'd like to, but we're working to expand the feature set and technologies we cover. If you had a particular use case that was not well covered, I'd love to learn more about it so we can evaluate related improvements. You can reach me at daniel at gitlab dot com. Thanks.

waltera 7y ago

We had a very similar experience with Gitlab too. Our teams evaluated Gitlab for a year before completely migrating away from it (to Github Enterprise for SCM, Confluence for wiki, YouTrack for issues and TeamCity for CI). Not a single team (out of 20) was happy with the overall performance (and especially the performance of code search). As far as wiki is concerned, Confluence's UI has its own share of issues, even after their recent overhaul, but all in all it is much better product. YouTrack and TeamCity are simply much more polished & stable products and are (in our experience) easier to administer than the competing offerings from Gitlab.

sytse 7y ago
Code search is not good at GitLab.com at the moment. We're working to enable ElasticSearch for GitLab.com to improve the situation https://about.gitlab.com/2019/03/20/enabling-global-search-elasticsearch-gitlab-com/ https://about.gitlab.com/2019/03/20/enabling-global-search-e...
phikai 7y ago
> Not a single team (out of 20) was happy with the overall performance (and especially the performance of code search). Hi! I'm the current PM for our search and as Sid mentioned we've steadily been working to improve that. It's been getting a lot better, but most of the improvements are heavily reliant on also having Elasticsearch enabled. Without that, there's really no way for us to provide a optimal search experience for the amount of data and content there. If you have any specific search feedback, please feel free to open an issue or reach out to me @phikai on GitLab.

milofeynman 7y ago

They love producing public facing verbose process documents... At first I thought, oh these are some neat ideas, but the more that they produce, the more I wonder how they get anything done with so much (verbose) process.

williamchia 7y ago
I work at GitLab and can shed some light here. As a 100% remote company we work in all timezone. Writing things down actually helps make things more efficient. At my last job, to get anything done I needed to call a meeting because state lived in people's heads. When someone left, of if you couldn't get them to a meeting, it was very painful. It took forever to get things done because you needed to physically be present in order to work. At GitLab because so much is documented it's easy to pick up state and collaborate with co-workers in all timezones. What's cool, is because it's public, other random people will jump in and help you out that you'd never expect since they have access to everything you have.

waylandsmithers 7y ago

I don't use Gitlab but still appreciate what they are trying to do. I think it's good to have competition and options in this space.