A GitHub for maintainers - Giving dependencies the same treatment the fork got
-
A GitHub for maintainers - Giving dependencies the same treatment the fork got
-
A GitHub for maintainers - Giving dependencies the same treatment the fork got
@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.
-
@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
-
@djc I think it could be ran cheap enough, especially if it’s not ran on every commit
@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.
-
@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.
@djc could probably do the same for go and java too
-
@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.
@djc also only needs a subset of dependents, not every single one
-
@djc could probably do the same for go and java too
@andrewnez
I'm obliged to do some advertising for tools that were developed in a research context for just this use case: https://github.com/alien-tools/breakbot for Java, with static analysis (by Ochoa, Degueule and @jrfaller) and https://github.com/rocq-community/coq-nix-toolbox for Coq/Rocq project but which would be feasible to generalize to other ecosystems (by Cohen and me).
@djc -
A GitHub for maintainers - Giving dependencies the same treatment the fork got
@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. -
@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"? -
A GitHub for maintainers - Giving dependencies the same treatment the fork got
@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
-
R relay@relay.mycrowd.ca shared this topic
