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

Every software system used at Gitlab

about.gitlab.com

Post reply on HN
Print view View original

71–80 of 123 posts

Re: Every software system used at Gitlab

#71

Post by masonhensley »

dtech wrote: post #40
echelon wrote: post #23

Earlier quoted context omitted.

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 Sale…

You severely, severely , underestimate the complexity and business value of a CRM

Been there, done that. Agree with dtech.

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.

Re: Every software system used at Gitlab

#72

Post by sytse »

spondyl wrote: post #30

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, techni…

On the go to market side the registry is a Google Sheet. On the GitLab.com infrastructure side it is an app we made that isn’t integrated into GitLab.

I’m seeing if we can move the sheet to the handbook and integrate the app into GitLab itself.

Re: Every software system used at Gitlab

#73

Post by sytse »

lazyjones wrote: post #66
sytse wrote: post #7

Earlier quoted context omitted.

Correct! If someone is more interested in what GitLab itself consists of please see https://docs.gitlab.com/ee/development/architecture.html#com...

The diagrams are nice, but it would be so much better if the nodes were linked to documentation.

I agree. BTW I’m not sure that mermaid allows you to link items in a diagram to the docs.

Re: Every software system used at Gitlab

#74

Post by andr3 »

jbaiter wrote: post #39
teen wrote: post #31

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 t…

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.

Epic: https://gitlab.com/groups/gitlab-org/-/epics/516

Issue for the checking of file seen (including the concept of "unread diffs"): https://gitlab.com/gitlab-org/gitlab/-/issues/24629

If you could please add your thoughts in that issue, we could use that feedback while we develop the feature.

Thanks a bunch for caring and voicing your concerns. It helps us get better.

Re: Every software system used at Gitlab

#75

Post by andr3 »

teen wrote: post #31

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 t…

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.

Recently we made the loading happen in batches which resulted in a significant improvement in how fast we start showing the diffs. https://gitlab.com/groups/gitlab-org/-/epics/1816

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.

Some examples:

* Commit navigation, to help commit by commit review: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28596

* File by file mode of reviewing MRs, including the concept of "unread diffs": https://gitlab.com/groups/gitlab-org/-/epics/516

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).

If some of your problems are not covered by these, feel free to open an issue (https://gitlab.com/gitlab-org/gitlab) and tag me as well.

Again, thanks for the feedback.

Re: Every software system used at Gitlab

#76

Post by edumucelli »

swah wrote: post #49
threeseed wrote: post #14

Earlier quoted context omitted.

Because it is the source of truth for all of your customers both current and future. And surely customers should be the centre of everyone's business.

Like OP, I'd love to understand better what Salesforce does (so well, it seems). Its a bit hard to imagine, just like SAP software (for me), since all your experience is on industries far from that world.

In their documentation Gitlab explains the usage they have of Salesforce, you may get a non-Gitlab specific view of it, for example: https://about.gitlab.com/handbook/customer-success/using-sal...

Re: Every software system used at Gitlab

#77

Post by jbaiter »

andr3 wrote: post #74
jbaiter wrote: post #39

Earlier quoted context omitted.

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. Epic: https://gitlab.com/groups/gitlab-org/-/epics/516 Issue for the checking of file seen (including the concept of "unread diffs"): https://gitlab.com/gitlab-org/gitlab/-/issu…

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!

Re: Every software system used at Gitlab

#79

Post by afandian »

sytse wrote: post #68
afandian wrote: post #46

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…

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.

Re: Every software system used at Gitlab

#80

Post by andr3 »

malikolivier wrote: post #37
teen wrote: post #31

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 t…

I can relate. We use GitLab at our company. 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.

Thanks for the comment.

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 "per commit" review, we're working on something to make this navigation easier and easier and shipping it very soon. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28596

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.

Thanks!

Post reply on HN