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

Gitlab More Than Doubles Valuation to $2.75B Ahead of Planned 2020 IPO

forbes.com

Post reply on HN
Print view View original

261–270 of 368 posts

Re: Gitlab More Than Doubles Valuation to $2.75B Ahead of Planned 2020 IPO

#261

Post by shmerl »

Ajedi32 wrote: post #142
petercooper wrote: post #82

Does anyone know why GitLab hasn't taken off so much amongst open source projects? I have no horse in the race (indeed, I'd love for there to be more variety in this space) but one of my jobs is to link to open source repos and I've just checked.. and the last one I linked to was in December 2018. In the niches I cover, almost no-one seems to actually using GitLab for their open source repos. Lest you think it's just…

It's the network effect. GitHub was first-to-market. Almost all open source contributors have a GitHub account these days. Many older projects started there long before GitLab was a viable competitor. Now assume you're starting a new open source project. Most of the other open source projects you've seen are hosted on GitHub. Most of the other developers you interact with have GitHub accounts. GitLab has all the same…

Many still choose Gitlab, since it's not associated with MS.

Re: Gitlab More Than Doubles Valuation to $2.75B Ahead of Planned 2020 IPO

#262

Post by emilycook »

aspaceman wrote: post #248
emilycook wrote: post #236

Earlier quoted context omitted.

Hi! I'm on Djorde's team, just in case anyone stumbles across this and thinks you're literally talking to a bot (not saying you are OP, just preventative), he is a non-native English speaker but definitely a real person. You're talking to this guy :) https://about.gitlab.com/company/team/#sumenkovic

I think the point they were making (in a mean way) is that it sounded like robotic PR speak, the thing any PR person would say. The support page doesn't say much about the quality of support, so the message was received poorly. Sometimes the very friendly PR tone is considered out of place and obviously forced. Especially on a developer forum. [PR for devs must be so much "fun" - you have my sympathies]

Hi, yeah I figured that was the point they were making, I kinda wanted to provide the info (in a round-about way lol) that he specifically is a non-native English speaker, so that's why it comes off as a bit forced-friendly and PR-ish. I do appreciate this feedback from both of you, I will mentor them a bit better about this!

Re: Gitlab More Than Doubles Valuation to $2.75B Ahead of Planned 2020 IPO

#263

Post by urbanjunkie »

scient wrote: post #147
aeonflux wrote: post #45

Earlier quoted context omitted.

I can totally relate to that. In flood of notifications I missed information about expiring CC. Instead of somehow soft-locking the account they just downgraded it and all my integrations, hooks and god knows what just blowed. I managed to fix the CC in 5 minutes, but many months after I am still recovering from that disaster. Support replied that they did send warning so I should just FO.

So you are blaming them for your own fault?

You are an unpleasant little cunt, aren't you?

Re: Gitlab More Than Doubles Valuation to $2.75B Ahead of Planned 2020 IPO

#264

Post by emilycook »

jonbronson wrote: post #242

Still waiting on better monorepo support in GitLab.

Hi! Better support for monorepos is in our roadmap, you can see our handbook entry here: https://about.gitlab.com/direction/verify/continuous_integra...

and the relevant epic: https://gitlab.com/groups/gitlab-org/-/epics/915

Re: Gitlab More Than Doubles Valuation to $2.75B Ahead of Planned 2020 IPO

#266

Post by oh_boy »

joshlambert wrote: post #206
oh_boy wrote: post #189

Earlier quoted context omitted.

Not sure what exact experience you made with the GitLab support but I can tell you our experience is different. It took over two months to resolve a license request we made to their support (or sales team) with multiple pushes from our side, every week. There are bugs with the CI system like an issue with the cache retrieval when multiple jobs run in different pipelines parallel to each other, that is actually blocki…

Hi - I'm sorry for the experience you had. I'm the PM for our Runner team, and we're focusing our next milestone purely on fixing some high priority outstanding bugs, that have been open for longer than they should have. Is this the issue you are referring to about the cache issues? https://gitlab.com/gitlab-org/gitlab/issues/21409 If so, it seems like it got lost in our triage system, I've set appropriate labels so…

The one your referencing is related or the same issue. The very first mention of the problem I found with my initial search probably a year ago was the following issue from 2016, which is the one I'm watching:

https://gitlab.com/gitlab-org/gitlab-runner/issues/1151

Re: Gitlab More Than Doubles Valuation to $2.75B Ahead of Planned 2020 IPO

#267

Post by croo »

shmerl wrote: post #261
Ajedi32 wrote: post #142

Earlier quoted context omitted.

It's the network effect. GitHub was first-to-market. Almost all open source contributors have a GitHub account these days. Many older projects started there long before GitLab was a viable competitor. Now assume you're starting a new open source project. Most of the other open source projects you've seen are hosted on GitHub. Most of the other developers you interact with have GitHub accounts. GitLab has all the same…

Many still choose Gitlab, since it's not associated with MS.

Or simply want a self hosted solution.

Re: Gitlab More Than Doubles Valuation to $2.75B Ahead of Planned 2020 IPO

#268

Post by Aeolun »

gabeweaver wrote: post #214
rossmohax wrote: post #202

Earlier quoted context omitted.

We are Gitlab customers since 2017 and I can tell you that your expectations for what support can do for you are very unrealistic. Per their own policy all they do is finding relevant tickets and send you there, from there on you are not their problem anymore. You as customers is also not a developer/product manager problem either, they do their planning and priotization using their own ideas and unless ticket is in…

Hi. GitLab PM here. I'm really sorry that this is your experience. Can you point me to this policy? I would like to propose a change to it given that's not reflective of how most teams do planning and prioritization. We care very much about support issues, regularly prioritize a large portion of each release to addressing them, and can not do it effectively without ongoing involvement and feedback from the wider comm…

> I will say that it is sometimes hard to separate the signal from the noise, given my team currently has 3k+ open issues.

I think this is a different problem. But not something your customers should have to care about.

Re: Gitlab More Than Doubles Valuation to $2.75B Ahead of Planned 2020 IPO

#269

Post by Merad »

emilycook wrote: post #260
Merad wrote: post #221

Earlier quoted context omitted.

Our devops team loves Gitlab pipelines and pushed the decision through. If you're looking for a "killer feature" on Gitlab, pipelines is probably it. As a developer I don't think there's a huge difference, especially since we don't use the issue tracking or wiki stuff (we're all in Jira/Confluence). My main complaint about Gitlab is that there are a lot of places where the UI is rough around the edges (lots of pages…

Hi! GitLab employee, thank you for your feedback! I'm going to distribute it to the correct teams, but I wanted to respond to a few points: > when you look at the team list in Gitlab, it shows everyone who has access to the team This has been an ongoing issue for a while, but a fix is currently scheduled for 12.4: https://gitlab.com/gitlab-org/gitlab-foss/issues/44958 > server squashing commits You don't have to prov…

Thanks for taking the time to respond!

Re squash commits: as a MR author what I want is the ability to set the commit message in advance (even if it's just a check box to say "use the MR title and description". Using a commit message is a sane default behavior, but not extremely helpful most of the time (IMO). If I'm going to rely on it for the message in my squashed commit I'm going to have to remember to check my branch history, and most of the time I'll probably have to do an interactive rebase to clean things up and ensure Gitlab grabs the correct commit message. It also negates the value of "squash on the server" - if I need to do an interactive rebase anyway, it only requires about 30 seconds extra to just do the squash myself.

Post reply on HN