Grafana releases OnCall open source project • Hacker News Board

Re: Grafana releases OnCall open source project

#131

Post by morelisp » Thu, Jun 16, 2022, 10:08 AM UTC

dijit wrote: post #130

morelisp wrote: post #128

Earlier quoted context omitted.

For SC security, the fewer points of attack between me and the source the better. For other kinds of quality, I have my own tests which are much more relevant to my use cases than whatever the distro maintainers are doing. I've been a DD and while distros do work to integrate disparate upstreams as well as possible, they rarely reject packages for being fundamentally low quality or make significant quality judgements…

I have seen scenarios where package maintainers have rejected updating packages because the upstream is compromised though.

Fedora currently packages 10646 crates. It's implausible that they're manually auditing each one at each upgrade for anything other than "test suites pass", let alone something like obfuscated security vulnerabilities.

In the end most distros will be saved by the fact they don't upgrade quickly. Which is also accomplished by MVS without putting another attack vector in the pipeline.

Re: Grafana releases OnCall open source project

#132

Post by smcnally » Thu, Jun 16, 2022, 11:14 PM UTC

deathanatos wrote: post #114

pm90 wrote: post #110

Earlier quoted context omitted.

I knew Pagerduty was going down the toilet when their sales folks started aggressively pitching BS products nobody really needed before their IPO. They couldn’t even release a proper incident management tool. I really hope this project gets good enough to ditch PD. PD should literally lay off most of its staff and just maintain the existing product, cut costs and focus mostly on integrations. There is no way they hav…

I agree with the weird pushiness on other products that add specious business value, but I do think there is room for feature growth in the main product. For example, the auto-merge functionality is somewhat useful, but it sometimes gets it wrong. Both merging and splitting alerts is extremely clunky. I'd also love to be able to have policies like "this alert is low-priority outside of business hours". The ability to…

    > … the sort of spit & polish that doesn't happen, IMO, anymore, because everything is an MVP feature, before the agile scrum PM moves on to the next MVP feature. "Polish" just accumulates in the JIRA graveyard.

This is the #1 complaint about Agile I've heard from customers, engineers, and The Business. "The team under-promised, under-delivered, and told us 'that'd be in the next sprint.' We've never seen a .1 release of anything."

It eats away the trust and collaboration that get good work Live and adopted. IYO, is this an indictment of "Agile," or more of that org's approach to it?

Re: Grafana releases OnCall open source project

#133

Post by dijit » Mon, Jun 20, 2022, 1:45 AM UTC

morelisp wrote: post #131

dijit wrote: post #130

Earlier quoted context omitted.

I have seen scenarios where package maintainers have rejected updating packages because the upstream is compromised though.

Fedora currently packages 10646 crates. It's implausible that they're manually auditing each one at each upgrade for anything other than "test suites pass", let alone something like obfuscated security vulnerabilities. In the end most distros will be saved by the fact they don't upgrade quickly. Which is also accomplished by MVS without putting another attack vector in the pipeline.

No person manages more than 250 packages (and he's a RH employee).

There's more than a hundred package maintainers (I'm not sure exactly how many), but the median is about 50 packages.

Do you think people can't keep up with the updates for 50 packages?

Re: Grafana releases OnCall open source project

#134

Post by morelisp » Fri, Jun 24, 2022, 11:13 PM UTC

dijit wrote: post #133

morelisp wrote: post #131

Earlier quoted context omitted.

Fedora currently packages 10646 crates. It's implausible that they're manually auditing each one at each upgrade for anything other than "test suites pass", let alone something like obfuscated security vulnerabilities. In the end most distros will be saved by the fact they don't upgrade quickly. Which is also accomplished by MVS without putting another attack vector in the pipeline.

No person manages more than 250 packages (and he's a RH employee). There's more than a hundred package maintainers (I'm not sure exactly how many), but the median is about 50 packages. Do you think people can't keep up with the updates for 50 packages?

I think I don't want "more than a hundred" additional points of trust, especially if they're trying to audit 50+ projects with various levels of familiarity each. And no, I don't believe one person can give a real audit to 50 packages each release even if was their actual job.

To paraphrase, all "more than a hundred" of those people need to be lucky every time.