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

Maturity

about.gitlab.com

Post reply on HN
Print view View original

101–110 of 127 posts

Re: Maturity

#101

Post by dgruesso »

rossmohax wrote: post #79
Narty wrote: post #76

Earlier quoted context omitted.

Turn is off then? https://docs.gitlab.com/ee/user/admin_area/settings/continuo...

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

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

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.

Re: Maturity

#102

Post by barret7sc »

ecbrinkman wrote: post #95
trumbitta2 wrote: post #90

I'll add my two cents and feedback: I like the GitLab flow, and I absolutely love the "Create merge request" button in the issue detail. I miss it dearly whenever I'm working on GitHub, and `hub pull-request` isn't quite the same. I don't like the code review functions: for example when I'm in the changes tab, where I can both resolve discussions and double-check the code, cycling through unresolved discussions break…

Thanks for the feedback. I just spun up a test MR ( https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/... ) to understand if I could quickly see what was bothering you on cycling through unresolved discussions but it seems to be working ok. Would it be possible for you to elaborate a bit more or link me to a MR where you can replicate the breaking functionality? I did notice there's a bug where the hover te…

My biggest issue with gitlab code review is that it's unusable for large changes and large files. On large changes it sometimes won't even show all the changes.

Also the auto-collapse size is far too small, and the fact you can't even see the diff for some large changes in infuriating. It makes using it for code review a struggle. My company is trying to move us all to gitlab-ee, but the lack of features and polish to the code review tool is preventing some teams from making the jump.

I feel like the code review portions are more like a half-circle, and not a heart. There are so many deficiencies that make it unusable for large projects.

If I were gitlab I would look at gerrit for inspiration on what you should use for code review. It's ugly, but it's very functional and performs quite well on meager hardware.

I know there are feature requests to make code review more usable but I can't understand how you could dogfood that code review tool and not go insane.

Also, merge trains for FF-only repos, please!

Re: Maturity

#103

Post by whoisjuan »

jrochkind1 wrote: post #88
whoisjuan wrote: post #37

Earlier quoted context omitted.

Net Promoter Score. Is a score calculated with a periodic survey that tries to determine cohorts of promoters (people who like your product so much that they are willing to recommend it to colleagues) and detractors (people who hate your product so much that they usually talk bad about your product if the opportunity to do so arises.) This is calculated through those surveys you get sometimes that say something along…

Huh, I'm confused how that score would tell you if a particular specific feature/area of the app provided "an elevated user experience that customers love". Any ideas?

Hmm. Good question. In my experience an NPS study isn't just the survey. I have done it in the past and usually after you get the results you do a baseline a call/contact your promoters and detractors to learn more about their issues.

So I think it's determined by a combination of personal reach-outs and probably the same questions scoped to particular features.

Re: Maturity

#104

Post by bobbylarrybobby »

johnsnowtho wrote: post #96

I moved all my repos to GitLab almost 2 years ago. I just use the online version. One of the main reasons I moved was because of price (free), and the available CI. I use a $5 DO droplet to do all my CI running - which gets me unlimited usage. It's awesome, and has only had to be rebuilt once it 2 years due to unresponsiveness. I've been a big fan of the CI - I use it to build my Docker images, then they get run on k…

Since MS acquired GitHub, GitHub also has free private repos

Re: Maturity

#105

Post by marinj »

rossmohax wrote: post #75

Gitlab isn't big company, 100 devs or so, they try to target much bigger fish (>2000 devs) with their product, yet they can't make it work even for their scale: Kubernetes , monitoring, CI workflows like merge trains and others. So when it comes to putting you money (gitlab.com subscribers) where you mouth is (gitlab.com/features page) they are not there yet. Kubernetes story is quite telling. They released "cloud na…

> yet when they just dip their toes into kubernetes world, when they switched their docker image registry to run on kube, they've quickly discovered glaring omissions like missing liveness probe and storm of errors on any version update.

You are right, we had some missteps with the Helm chart that were unfortunately not discovered by others or us. Our test cases of scaling registry up and down worked perfectly in all our synthetic tests we did so it was not obvious to us that the liveness probe was missing. In hindsight it is quite obvious but at that time we had 16 other charts to write and some things did slip through. For a number of other services, community and paying users were reporting issues that we solved as we went further. Registry is one of the components that receives traffic in bursts so for majority of users this was probably never an issue or it was one of those "gremlin" moments.

For GitLab.com the things are quite different. We hold 2PB of data in docker images alone and there is continuous flow of traffic. For GitLab.com scale, none of the services we are porting to K8s have the luxury of the bursty traffic so we are careful in how and when we switch over traffic. The good thing is that all the edge cases we found are fixed and now in the Helm charts releases so that users can really put this on k8s as ready. If you are curious on all the issues we had to cover during this process, see the main registry migration epic https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/70 .

Re: Maturity

#106

Post by ibaum »

marinj wrote: post #105
rossmohax wrote: post #75

Gitlab isn't big company, 100 devs or so, they try to target much bigger fish (>2000 devs) with their product, yet they can't make it work even for their scale: Kubernetes , monitoring, CI workflows like merge trains and others. So when it comes to putting you money (gitlab.com subscribers) where you mouth is (gitlab.com/features page) they are not there yet. Kubernetes story is quite telling. They released "cloud na…

> yet when they just dip their toes into kubernetes world, when they switched their docker image registry to run on kube, they've quickly discovered glaring omissions like missing liveness probe and storm of errors on any version update. You are right, we had some missteps with the Helm chart that were unfortunately not discovered by others or us. Our test cases of scaling registry up and down worked perfectly in all…

It is also worth nothing that over time, the omnibus-gitlab package has benefited greatly from being used to deploy to GitLab.com. As we migrate more of the workloads into kubernetes using the charts, we expect to see some of the same benefits and insights there. See our handbook for more details on how we use dogfooding: https://about.gitlab.com/handbook/engineering/#dogfooding

Re: Maturity

#107

Post by joshlambert »

whoisjuan wrote: post #103
jrochkind1 wrote: post #88

Earlier quoted context omitted.

Huh, I'm confused how that score would tell you if a particular specific feature/area of the app provided "an elevated user experience that customers love". Any ideas?

Hmm. Good question. In my experience an NPS study isn't just the survey. I have done it in the past and usually after you get the results you do a baseline a call/contact your promoters and detractors to learn more about their issues. So I think it's determined by a combination of personal reach-outs and probably the same questions scoped to particular features.

Hi - we've been discussing how to better anchor these on quantitative data, rather than the subjective opinion of GitLab PM's.

You can see some of the discussion here (https://gitlab.com/gitlab-com/Product/issues/323) which continued to some degree here (https://gitlab.com/gitlab-com/Product/issues/386).

If you have feedback on some other metrics to use, please contribute! I don't think we've landed on the right formula just yet. But directionally, we'd like these to be based on user outcomes rather than our own opinion.

Re: Maturity

#108

Post by meks »

ori_b wrote: post #27
KaoruAoiShiho wrote: post #8

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.

I don't really use gitlab, but I wrote my own git implementation recently ( 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…

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

Re: Maturity

#109

Post by jramsay »

barret7sc wrote: post #102
ecbrinkman wrote: post #95

Earlier quoted context omitted.

Thanks for the feedback. I just spun up a test MR ( https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/... ) to understand if I could quickly see what was bothering you on cycling through unresolved discussions but it seems to be working ok. Would it be possible for you to elaborate a bit more or link me to a MR where you can replicate the breaking functionality? I did notice there's a bug where the hover te…

My biggest issue with gitlab code review is that it's unusable for large changes and large files. On large changes it sometimes won't even show all the changes. Also the auto-collapse size is far too small, and the fact you can't even see the diff for some large changes in infuriating. It makes using it for code review a struggle. My company is trying to move us all to gitlab-ee, but the lack of features and polish t…

> it's unusable for large changes and large files. On large changes it sometimes won't even show all the changes.

Improving the performance and scalability of merge requests is the priority for the Source Code team right now, and we are starting with progressively loading the diffs over coming releases. See https://gitlab.com/groups/gitlab-org/-/epics/1816. Currently we load them in a single request which is a serious bottleneck.

In parallel we are exploring a range of UX changes to streamline and improve the code review experience. If you have any specific ideas please let us know, or create an issue!

> Also, merge trains for FF-only repos, please!

Absolutely! We are iterating towards this https://gitlab.com/gitlab-org/gitlab-ce/issues/58226!

Re: Maturity

#110

Post by rossmohax »

ibaum wrote: post #106
marinj wrote: post #105

Earlier quoted context omitted.

> yet when they just dip their toes into kubernetes world, when they switched their docker image registry to run on kube, they've quickly discovered glaring omissions like missing liveness probe and storm of errors on any version update. You are right, we had some missteps with the Helm chart that were unfortunately not discovered by others or us. Our test cases of scaling registry up and down worked perfectly in all…

It is also worth nothing that over time, the omnibus-gitlab package has benefited greatly from being used to deploy to GitLab.com. As we migrate more of the workloads into kubernetes using the charts, we expect to see some of the same benefits and insights there. See our handbook for more details on how we use dogfooding: https://about.gitlab.com/handbook/engineering/#dogfooding

Every case of dogfooding brings tremendous benefits to the depth and quality of your offering, no doubt about it and these improvements are very much welcome. Issue I have is not with dynamic, but with the current state of affairs, were wide spectre of features are presented as ready, yet they are not as high quality as Gitlab marketing.
Post reply on HN