Hacker Newsnew | past | comments | ask | show | jobs | submit | joshlambert's commentslogin

> "Advanced" search is completely useless as you can't really search for code.

@deng - thanks for the feedback. I am on the Product team for our Search service, code search is not where we would like it to be.

We are in-progress on swapping out the backend for code search from Elastic to Zoekt, which should provide a much more reliable and complete set of search results. You can read more about our plans for fixing code search here: https://about.gitlab.com/direction/global-search/code-search...

This is the key deliverable for the team, and we are making efficient progress. If you have feedback on our plans, we would love to hear it. The epic is here: https://gitlab.com/groups/gitlab-org/-/epics/9404


@cmckn - PM @ GitLab here - sorry to hear you had a poor experience with running our GitLab chart on k8s. We've been trying really hard to make this easier, but there is still some room to go especially on the documentation front: https://gitlab.com/groups/gitlab-org/-/epics/5273.

I'd love to hear what you had trouble with, so we can continue to improve. If you'd like, can also open an issue here: https://gitlab.com/gitlab-org/charts/gitlab/-/issues


Hi, GitLab product manager here. I'm sorry that we haven't provided a good experience. We try really hard to make sure GitLab deployments "just work", and clearly it does not for either of you.

Both Puma and Unicorn should be killed after they exceed a certain size to avoid this situation from happening. It's possible either this is not working in some situations/configurations, or there is a leak elsewhere although this is the first time I have heard reports of this.

What configuration is being changed from the defaults? Alternatively if you could open an issue with any additional detail we will try to figure out what is happening and fix it: https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues


Thanks for the feedback entha_saava. GitLab.com is indeed slower than GitHub.com today, and we need to provide a better experience for our users.

Improving frontend performance is a key focus area for us, and while we started this specific initiative recently, we have started prefetching data while our Vue app is loading (https://gitlab.com/gitlab-org/gitlab/-/issues/220511) and will be splitting out page specific assets out of the main bundle (https://gitlab.com/groups/gitlab-org/-/epics/3694).

We have quite a few other initiatives in flight, and will continue to provide updates on progress which you can see here: https://gitlab.com/groups/gitlab-org/-/epics/3273#note_37091...


Please read through the upgrade notes for 13.0 as there are some important changes like PG11 being a minimum requirement.

As for the actual upgrade, you should be able to follow the standard process outlined here since you are persisting your data outside the container: https://docs.gitlab.com/omnibus/docker/#update


Updated without any issues, thanks.


The breakdown is probably close to the percentage of paying versus open source customers that we have.

We are working to better educate our users on the value that our paid version can offer, but it is very important for us to be good stewards of the open source community that has grown around the project. You can read more about our pricing strategy and stewardship here: https://about.gitlab.com/company/stewardship/#what-features-...

On the revenue side, Sid publicly shared an update recently: https://twitter.com/sytses/status/1156571842653478913?s=21


please stop astroturfing.


He's not astroturfing, astroturfing requires deception.


whatever you want to call it, it’s spammy and more than a little desperate.


Sorry if you find this spammy! It's huge news for us and we all (of course lol) have a vested interest in making sure the company succeeds. Since we don't have Microsoft funding to enable us to throw resources at everything in our backlog, we rely heavily on user experience to help us prioritize. Which just so happens to come up much more organically on sites where devs are more empowered to voice their opinions freely :)


Nonsense. You have hundreds of employees and a multi-billion dollar valuation, and you keep making the same excuses.

I have been watching you folks spam threads, over and over again, for years, with the same things: “we’re fixing performance!”, “making the UI better is a priority!”

The user complaints never change.

Instead of spamming threads with guerilla marketing, make your software better. What was cute when the company was four guys and a computer now just appears calculated and manipulative.


Hi, we do believe in the single application offering the best long term user experience and outcomes, but do understand that all of our features may not work for everyone. This is happens for a variety of reasons (completeness, migrations, specific project requirements, etc.)

Because of this, we do offer our API and the ability for our community to contribute integrations directly to the codebase. We have a pretty rich set today, you can see at: https://docs.gitlab.com/ee/user/project/integrations/project...

We're also working to further improve our integration options, with a dedicated team: https://about.gitlab.com/direction/ecosystem/. This team will be responsible for our broader API, an upcoming SDK, as well as continuing to improve our existing integrations like JIRA and Jenkins. This team is just getting under way, but I wanted note our investments here.

> Github API integration is stellar, API token permissions can be configured granularly, Github apps marketplace is awesome way to start using third party services.

PAT granularity has indeed been a pain point, and we should be solving this soon by offering the ability to restrict them by groups/projects: https://gitlab.com/groups/gitlab-org/-/epics/182


Integrations go both ways. While Gitlab debates how to strip down Junit XML test result processing or represent arbitrary artifacts , Github has Checks API https://developer.github.com/apps/quickstart-guides/creating... where any third party system can provide feedback on a pull request and even veto it's merge.

Gitlab has many strengths, but integrations is by far the weakest one.


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 now it should get the appropriate visibility.


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


Hi - thanks for the feedback, we aren't where we want to be with performance. We are working hard to improve responsiveness and memory consumption, and have a recently started a team focused on just these aspects to accelerate the improvements. You can read more about the rationale here, including stories like yours: https://about.gitlab.com/2019/09/13/why-we-created-the-gitla...

One of the major projects the team is working on, is to switch from unicorn to puma: https://docs.gitlab.com/omnibus/settings/puma.html

We are also continuing our broader effort at improving performance each release, for example in 12.2 we had 58 MR's focused on performance improvements: https://about.gitlab.com/2019/08/22/gitlab-12-2-released/#pe...

Hopefully you will start to feel the impact of these investments soon.


Hi - just wanted to confirm that this issue has been addressed and will be included in our 12.4 runner release.

MR: https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: