Post
@andrewnez re "Fork networks":
hypothesis: in the current status quo the search for a fork is delayed until it is no longer possible (f.e. due to a security issue or incompatibility with a new major version of another dependency). so people are looking for a fork in a moment of crisis which might lead to insufficient security consideration.
so this feature has the potential to encourage earlier switches (esp. if integrated into dep managers) but it also could be gamed by malicious actors.
@andrewnez re "Fork networks":
hypothesis: in the current status quo the search for a fork is delayed until it is no longer possible (f.e. due to a security issue or incompatibility with a new major version of another dependency). so people are looking for a fork in a moment of crisis which might lead to insufficient security consideration.
so this feature has the potential to encourage earlier switches (esp. if integrated into dep managers) but it also could be gamed by malicious actors.
@lsmith all the public fork events show up in the gharchive firehose, so it’s not a lot of security
@andrewnez I suspect that the "downstream testing" you describe cannot be done because most downstreams use package managers resistant to MITM. There's no way for you to inject a release into their CI.
I want this so bad.
It doesn't even need to track every project under the sun, but if it's a library, the top 5 to top 10 projects that rely on it should give a good indication if the change is big and annoying or small.
@andrewnez back in 2015 we experimented with 'reverse PRs' for docker/go: so every time i pushed to the lib i maintain i'd get a report back of all the downstream users i'd broken. I still really want that
@andrewnez > Rename “issues”
Oh my glowcloud, yes, please! I would also add that users need a place to report incidents as a thing separate from a known defect. An incident could have multiple causes, or even an unknown cause.
@csepp
@andrewnez
while at it, why not add a, separate "known defect database" where things don't get closed by a stalebot / as "we don't have time for that"?
@andrewnez having something crater-like would be amazing, but it also seems very expensive, potentially prohibitively so? I do wonder if we could do the static analysis version of that at least for languages like Rust.
@djc I think it could be ran cheap enough, especially if it’s not ran on every commit
@andrewnez @djc Maybe run it if a commit gets given a release-candidate (*-rcN) tag?
@andrewnez maybe. And arguably it’s not all that different from triggering every downstream’s CI via Dependabot/Renovate after the release.
Though now I’m wondering for Rust if it would be feasible to do like a static analysis version of this, plowing through the rustwide corpus looking for specific code paths.
Install bonfire.cafe
Get the full app experience
