I'm so sick of Gitlab support spam in every thread that mentions any issue, making it so that critical conversations are interrupted with self serving pitches!
>I once saw Gitlab do this thing.
>Hey, Bob from Gitlab thing here. We are really trying to make thing great for our customers . Our next release of thing will do foo which we hope will fix this. Here is a link to a marketing post comparing us to GitHub. Hope that helps. Please don't mention us in a comment, or I have to do this. It hurts to live.
Hey, Jimmy here, vending machine manager at GitLab. I'm sorry that our posts here are concerning. I'm going to run this one right up the ladder for you. Thank you so much for your concern and sorry about your experience with GitLab!
Would you rather have say, Google’s style of replying on issues with deafening silence? I see your point though. I think it’s better this way. A company can be helpful or shoot themselves in the foot while they figure out to communicate. Too much salesy self-serving talk means they don’t take you seriously so why should you return the favor? Now you can find out easily.
The thing is - I get it. I thi k it's cool when people show up to talk about their product or code that is mentioned on a forum. It's endearing. But when it's systematized by a large corporation, it's no longer so.
We've just had a bad experience with GitLab annual renewal, to the point where we didn't know if they'd cancelled our account or not.
The billing accounts system seems to be completely disconnected from user accounts. A notification banner was spammed to users in the GitLab.com user interface, saying that our account was going to be cancelled becuase we didn't have auto-renew. The users who got the banner didn't have permission to act on it in the billing system. The billing system said that we _were_ on track to renew, which disagreed with the banner. Eventually it transpired that the end-of-year "truing up" meant that our account was on hold, but we weren't notified of this.
And when we _did_ pay the bill we get a banner saying "you've been downgraded to the free plan" when the gitlab.com interface says we hadn't.
It really undermined confidence in how well these systems are connected.
On the flip side, the fact that everything is open meant that you can see customer support reps raising internal bugs about this stuff. The principle of open-everything makes it more pallatable, but it doesn't make up for lost confidence.
I am a product manager at GitLab and my focus is on making renewals as easy and pain-free as possible for customers. I am very sorry that you had such a confusing and frustrating experience here. We are working on a number of issues that will improve this process, including:
I would love to chat with you to learn more about the challenges you experienced and to review some of our plans to make things better if you're up for it. You can reach me directly at mkarampalas[at]gitlab.com
Thanks, it's great to see that. Incremental true-ups would be very useful. My colleague is talking to an account manager directly, but I'll pass your message on.
Sorry that this happened. We still have a long way to go to improve our billing system. We have allocated more people to it since a few months and are making much faster progress. But it isn’t we’re it should be at the moment.
Thanks. No worries, these things happen. It's just a little alarming to see messages like "we've downgraded you to the free plan". Even a bit of help text in the banner, linking to a page on situations under which the message might be raised / not be 100% accurate, might ease the experience.
I'm not surprised. They currently refuse to have a sane policy around licensing people who just want to put in issues and view repos vs actual developers. They make all users count as a full developer, which makes no sense. Their reasoning is basically "its just easier for us" which is not the point. [0][1]
That's an entirely separate issue, so this seems like an ad-hominem. And possibly a bit off-topic for a thread about their system integration.
But that said, I do wholeheartedly agree! The top-tier account type allows free reporter-level users. But for every other tier (e.g. silver), you have to pay for them. I think that's big mistake, as the cost-benefit of paying 200 USD per year for each member leads to work-arounds, which compromises the user experience.
Gitlab has been pretty great so far, but the code review tooling is so poor I think I need to look elsewhere. The pull request pages take forever to load, they can't handle pull requests with over 800 lines well at all. It will collapse files with over 100-200 lines of changes for seemingly no reason (hiding the comments within them). You can't ignore whitespace in diffs, and the comments disappear from the diff if they push new commits, you need to look at them in the overview again.
Hi, Engineering Manager at GitLab here, Source Code team.
Thanks for the comment.
Indeed that is something we've had in our minds for a long time. Over the past months/years, we have been shipping out incremental improvements in the way we handle and render large MR diffs.
We plan to continue improving the performance of the MR page, lowering memory footprint this Q2 as well as providing other ways to enhance the experience.
We're constantly looking to improve and learn more about the struggles of our users. If you have further thoughts, please drop a comment in one of the issues and epics above and tag me (@andr3).
> It will collapse files with over 100-200 lines of changes for seemingly no reason (hiding the comments within them)
OH MY GOD this so much. This one specific anti-feature has no doubt caused countless bugs to be missed during code review. I can quote the issue thread by memory at this point i've revisited it so many times the last year(s?)
For goodness sake, if the trade off is between 'seeing all of the changes during the review' vs 'having the page load quickly', the only people who choose 'quickly' are those who haven't been burned by human error missing a collapsed diff. Gitlab made the wrong trade off here in good/fast/cheap triangle.
In my experience, if you are reviewing 800+ line PRs you should be in an IDE. I believe the average human being can not review an 800 line diff reliably.
Such large PRs would also probably benefit from live discussions over video (or in the good old days -- in person).
Interesting, I’ve only went through the effort of checking out a pull request for review a couple times. What’s the workflow like? Any tips for reducing friction? I avoid checking out PRs because it’s much higher friction and because I trust CI to catch most bugs so the crappy code forge interfaces are good enough.
Personally, I would kill for a one click to step review interface in IntelliJ that synced comments back to the review.
I still think the merge request UI is great. Its main problems are its slowness and the fact that files with a long diff are collapsed.
As the full merge request is quite slow, I will usually open the diff of each commit one by one, then put review comments as a "per commit" basis.
I've left a few replies in this thread already with more detail of work we have done, is currently in flight and work that is planned to keep improving the overall situation.
As to the collapsed, unfortunately if we loaded all diff lines expanded, the large changesets would make the browser unusable. We're working to lower the memory footprint and have better ways to deal with these large MRs.
One example I can leave you with that we're trying to figure out a way to make this useful as an additional option, is this:
* File by file mode of reviewing MRs, including the concept of "unread diffs": https://gitlab.com/groups/gitlab-org/-/epics/516
We're aware of several of the pain points (we use GitLab to build GitLab ;) ), but if you have further feedback, please leave a comment in the issues and epics I've left here (or create new ones) and feel free to tag me @andr3.
I don’t understand. This describes basically every code review tool I’ve ever used. If there’s something aside from Gitlab that I should try that still integrates, I’d love to know.
For huge diffs, there’s not much that beats `git checkout <branch> && git diff HEAD^`.
For leaving comments, pretty much every system I’ve used has issues. At work we use phabricator; the default settings are atrocious but they can be tuned to something workable.
I sometimes wonder how hard it would be to get diff reviews to be a first (or even second) class citizen of the git ecosystem. That way you can finally get the bliss of leaving review comments in the IDE. They already have “notes” which are vaguely similar, maybe it’s something they’re considering?
> [git ecosystem] have “notes” which are vaguely similar, maybe it’s something they’re considering?
If you're referring to git-notes, they are ... kinda special. They are objects in their own namespace that reference the repository objects the notes themselves are attached to.
Sure enough, you can attach a note to any git-object. And you can view them either directly or from the git-log view. But the discoverability is lacking, and the UI of doing pretty much anything with git-notes is absolutely atrocious. Because they are in their own namespace, you don't automatically get them when you do a pull or fetch, which can get pretty confusing.
For the curious ones, the magic invocation needed to pull in updates to notes from the remote repo is:
git fetch origin +refs/notes/*:refs/notes/*
Notes are not versioned, and you certainly don't get nice N-way merges between local and remote content. Semantics are different from regular git, and stuff can get lost.
So from where I'm looking at things, git-notes are not suitable for plumbing in a code review flow.
You're right, I was referring to git-notes and they aren't suitable as plumbing for code review :)
I was meaning to point out that we've developed plumbing for objects with "weaker" guarantees than source code, which can still be attached to refs. To me, this is indicative that the maintainers are willing to accept patches on things that are outside the "core mission" of versioning source code, and might mean that they're open to the idea of accepting a well-architected code review feature.
Although, you're also right, in that there's still a lot of plumbing to make sure that authors can only edit their own comments, and that sort of thing. The more I think about it, there's a lot of work to be done and it isn't easy.
But, if you made a proposal, I think git-notes is precedent for them accepting your contributions. :)
Yeah, this is definitely one of GitLab's weakest points at the moment and seriously impacts day-to-day work here as well. Simple features like ticking off files you've already reviewed are missing and even mid-sized MRs are a pain to review even on a beefy machine.
Hi! I'm an Engineering Manager at GitLab in Source Code team.
This is on our horizon. We have an Epic to track an overall revamp and adding an option to review file-by-file which will include developing something like what you just described.
Thanks a lot for taking the time to answer! I hope my criticism didn't come off too strong, overall I love working with GitLab, the parent just struck a chord with one of my pain points. Glad to see you're working on it!
I don't know if any Gitlabbers are in the comments but I'd be interested to know: Is this basically your internal asset register open sourced?
I suppose they're not particularly top secret but there could be a version that has some more sensitive data and this is a safe derivative for example. Similarly, such an asset register would likely have non-technical assets as well while this just seems to be tangible, technical things?
I figure any large company with a risk management function will already have/need such a spreadsheet (or document), complete with some sort of data classifications to exist for auditing reasons so the interesting step is maintaining it out in the public.
Kudos to Gitlab for having the culture to allow this sort of stuff :)
You'd be surprised the scale of companies that do not have this data. Or how many companies think they know where their data is but really don't. Especially with the proliferation of the SaaS services like you see in Gitlab's diagram. It's very easy for someone in the accounting or marketing department to sign up for something on their department's PCard and the IT / security / etc departments have no idea that company data is being kept there.
An asset register is how companies keep track of their assets. Any software license, computer, monitor, keyboard, copy machine, etc. the company claims as an asset is tracked in the register.
And HN users only worry about “cloud lock-in”. I’ve said dozens of times that the typical largish company is locked in to dozens of SAAS offerings that would be a major pain and expense to migrate away from.
Once you choose your infrastructure, you might as well go all in. Just look at their dependence on SalesForce.
I used to love GitLab, and I still do in a lot of ways but I will no longer recommend them.
If you're looking for a shiny pretty interface for all your users, then Gitea can serve the same purpose. Personally, I find cgit to look fine too. I think GitLab simply tries to do too much, and they've built their entire app on a poorly scalable and bloated tech stack.
I think SourceHut probably provides the best platform for teaching developers a more native way to use Git that provides most of the same features as GitLab. For CI/CD there are so many better options outside of GitLab that integrate into Kubernetes and you won't regret it.
How much money do you wager that Salesforce license costs?
I know there's the whole build-vs-buy debate, but with the cost of Salesforce, might it not be better to just stick everything in a database and throw a MySQL WYSIWYG tool like phpmyadmin in front in order to let non-engineers see the schema and build forms?
I suppose if you're earning money hand over fist (or keep getting VC funds) then the cost of your Salesforce license doesn't matter. But I bet that hurts. And unlike a lot of the other software in use, Salesforce comes with steep lock-in.
You also get to a point in hiring where the field of sales/ops people judge you & your maturity based on whether you use a commercial tool like Salesforce/HubSpot vs build your own.
Can you imagine joining a tech org and they have a half baked phpadmin wysiwyg as a standin for github + code reviews?
While yes, you could calculate out how much the subscription is vs development time to build a simple CRM, the maintenance & mental overload is righteously terrible. Better to spend that effort integrating your foos to your bars than building a sales crm.
Marketo eh? My wife mentioned wanting that in her small business after seeing a shiny video but I said the price is probably not going to be appropriate (some research seemed to support this). Does anyone have experience using it? I have mixed feelings about Adobe but don't know how much influence they wield.
If she wants to sell to enterprise Marketo is a good option because of the deal size / volume. Google uses it for selling Google Cloud Platform. Otherwise Hubspot is probably a better idea.
Enterprise is definitely not on the menu, and Hubspot or one of the similar alternatives does sound more around the level she'd need. I had some fun messing around with Mautic and it could be fun to learn, but I'm not sure how its future looks.
Acquisitions can go both ways and apparently the guy who invented and put a lot of sweat into it (dbhurley) has parted ways with the project. Also they used to produce a lot of media on using it, but it's all a couple of years old now. Maybe that means they got the fundamentals right back then but it does send a mixed message. I would love to try it, I've set it up and it seems to be working, but I'm just not sure what'll happen if something goes wrong (their forum moves a little slow too). I have no special knowledge, just a gut feel and outsider impressions.
This isn't a recommendation or advice but if you're after a ledger that's larger than what Xero can offer to a big org, Netsuite seems to be what Gitlab uses and is ironically enough also what Xero uses. Unfortunately (and somewhat ironically?) we're too big to actually have Xero run on Xero
If you’d like some feedback, for us it’s less a volume issue and more a case of design limitations. We run subledgers per customer in our own code for clearing and settlement (we’re a two-sided network), and posting the rollups back to Xero sometimes runs into edge cases and limitations. Recognition timing is one pain point, another is API-driven reconciliation.
What I’d struggle to give up is the ease of reporting. Xero’s report designer is right in my sweet spot for usability, flexibility, and domain-specific correctness, probably my favourite reporting tool in three decades of shaking down business software.
While I don't work on the product (directly) or speak in any official capacity, I can definitely route your pain points and compliments to the respective teams internally :)
Doesn't seem that much for Gitlab's size. And they are doing an effort to document it all and write it down instead of having it lie distributed in the minds of employees managing those services.
Curious about whether Salesforce represents a single point of failure. If it goes down or is unavailable, what impact does that have on the rest of the organization?
In some architectures it can be, which is a risk. A while ago I was in a day long kick off for a project to replatform a division of a large company, with Salesforce at the core. As it happens, one of the other division's Saleforce instance was down the whole day, bringing down everything. Internal systems, web, sales... everything broken.
We listened to the lesson and the architecture we designed ended up not having Salesforce as a dependency for any critical or money producing customer facing functionality.
We used Alteryx as a ETL tool to keep Salesforce in sync in almost real time. The customer facing sites and services ran off their independent databases. This also meant that the developers working on that didn't need to know the details about how Salesforce worked, we just mapped Salesforce data to their database.
can such a diagram be generated using text markup ? i want to have this in revision control and then generate this in a static page (Nextjs or Gatsbyjs)
mermaidjs [0] can do class diagrams that look kind of like this. It integrates into markdown via Jekyll easily, so I assume it will work well with gatsby.
It’s a basic text only structure so it actually diffs pretty well so I can see a merge request with a new node or new relationship.
They are a remote distributed team. I don't think their employees would value having to arrange their workspaces to accommodate a big screen set up high and at a distance from their workstation.
I work at GitLab and don't have children. My routine is pretty much... unchanged since COVID-19. That said, my stress is through the roof, as are other members of the team, not because of GitLab or deadlines or work, but life.
Those with kids, I know that it can be even more challenging or exhausting. so in some ways "unaffected" in others "feeling it". Pretty much like everyone else.
I can't comment specifics on finances, but I do count my lucky stars that GitLab raised when it did as it personally gives me a little more reassurance that we may be less affected. That said, obvs anything can happen to me or GitLab.
Our e-team recently sent out a company wide reminder that we are family and friends first and work second. As people start settling into “new normals”, they also encourage team members to take the time they need. My direct manager is reminding me to take the necessary time of to help school my kids during our 1:1's and continuously check if I need any further support.
As someone who has a B2B startup there is almost nothing in the open source space for Marketing/Sales Ops. And anything that does exist is really low quality.
And it's because (a) most developers aren't exposed to non-Engineering parts of the company so they have no understanding of what problem to solve and (b) it is incredibly lucrative to build a proprietary SaaS solution.
> there is almost nothing in the open source space for Marketing/Sales Ops
There is https://erpnext.com/ which is completely FOSS built on Frappe framework. If anything, it is rather higher quality than most SASS solutions out there.
It's not entirely clear on their website, but I assume the full software is at https://github.com/frappe/erpnext, and they have a model similar to Sentry?
Word of advice: stay away from Erpnext, don't get fooled by the apparent "clean" interface.
They might have some good conceptual ideas, but the implementation is horrific, their ops/delivery infrastructure a shitshow if even there's one, bugs all over the place and a product management that basically says yes to everything and finishes nothing.
They are in part victims of their own success, but just look at their Github issues page.
That kind of software is not fun or sexy, so people have to be paid to write it. Same goes for accounting where there are few open source solutions. Boring as hell, and profitable.
Funny how they don't seem to really have any non-specialised tools to coordinate, manage and track work in a structured way across the company (like smaller team tools like Trello, or larger ones like Asana). The only cross company collaboration tool I saw on that diagram was Slack!
Makes sense considering Gitlab _is_a cross-company collaboration tool; they eat their own dogfood. They have a whole set of features that compete directly with Trello/Asana
GitLab, here is my proposal: remove 80~90% of this. Keep the essential. Prove that you are a really innovative company. Stop following analytics. Engage with your users.
Prove that you can control entropy and recover your agility rather than going the bureaucratic enterprise software way, just waiting for a more hungry and foolish player to cut the grass under your feet.
>I once saw Gitlab do this thing.
>Hey, Bob from Gitlab thing here. We are really trying to make thing great for our customers . Our next release of thing will do foo which we hope will fix this. Here is a link to a marketing post comparing us to GitHub. Hope that helps. Please don't mention us in a comment, or I have to do this. It hurts to live.