<![CDATA[A GitHub for maintainers - Giving dependencies the same treatment the fork got]]>A GitHub for maintainers - Giving dependencies the same treatment the fork got

Link Preview Image
A GitHub for maintainers

Giving dependencies the same treatment the fork got

favicon

Andrew Nesbitt (nesbitt.io)

]]>https://board.circlewithadot.net/topic/f0049380-c584-4f0f-bff3-47a36859ac47/a-github-for-maintainers-giving-dependencies-the-same-treatment-the-fork-gotRSS for NodeFri, 15 May 2026 05:38:08 GMTSat, 02 May 2026 17:22:37 GMT60<![CDATA[Reply to A GitHub for maintainers - Giving dependencies the same treatment the fork got on Sun, 03 May 2026 11:46:58 GMT]]>@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

]]>https://board.circlewithadot.net/post/https://amok.recoil.org/users/avsm/statuses/116510478721178294https://board.circlewithadot.net/post/https://amok.recoil.org/users/avsm/statuses/116510478721178294Sun, 03 May 2026 11:46:58 GMT<![CDATA[Reply to A GitHub for maintainers - Giving dependencies the same treatment the fork got on Sun, 03 May 2026 07:03:27 GMT]]>@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"?

]]>https://board.circlewithadot.net/post/https://mstdn.io/users/wolf480pl/statuses/116509363927182700https://board.circlewithadot.net/post/https://mstdn.io/users/wolf480pl/statuses/116509363927182700Sun, 03 May 2026 07:03:27 GMT<![CDATA[Reply to A GitHub for maintainers - Giving dependencies the same treatment the fork got on Sat, 02 May 2026 22:10:00 GMT]]>@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.

]]>https://board.circlewithadot.net/post/https://merveilles.town/users/csepp/statuses/116507266290914352https://board.circlewithadot.net/post/https://merveilles.town/users/csepp/statuses/116507266290914352Sat, 02 May 2026 22:10:00 GMT<![CDATA[Reply to A GitHub for maintainers - Giving dependencies the same treatment the fork got on Sat, 02 May 2026 20:31:01 GMT]]>@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

]]>https://board.circlewithadot.net/post/https://fediscience.org/users/Zimm_i48/statuses/116506877049821041https://board.circlewithadot.net/post/https://fediscience.org/users/Zimm_i48/statuses/116506877049821041Sat, 02 May 2026 20:31:01 GMT<![CDATA[Reply to A GitHub for maintainers - Giving dependencies the same treatment the fork got on Sat, 02 May 2026 18:16:54 GMT]]>@djc also only needs a subset of dependents, not every single one

]]>https://board.circlewithadot.net/post/https://mastodon.social/users/andrewnez/statuses/116506349678996490https://board.circlewithadot.net/post/https://mastodon.social/users/andrewnez/statuses/116506349678996490Sat, 02 May 2026 18:16:54 GMT<![CDATA[Reply to A GitHub for maintainers - Giving dependencies the same treatment the fork got on Sat, 02 May 2026 18:15:06 GMT]]>@djc could probably do the same for go and java too

]]>https://board.circlewithadot.net/post/https://mastodon.social/users/andrewnez/statuses/116506342652637853https://board.circlewithadot.net/post/https://mastodon.social/users/andrewnez/statuses/116506342652637853Sat, 02 May 2026 18:15:06 GMT<![CDATA[Reply to A GitHub for maintainers - Giving dependencies the same treatment the fork got on Sat, 02 May 2026 18:14:32 GMT]]>@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.

]]>https://board.circlewithadot.net/post/https://hachyderm.io/users/djc/statuses/116506340368918410https://board.circlewithadot.net/post/https://hachyderm.io/users/djc/statuses/116506340368918410Sat, 02 May 2026 18:14:32 GMT<![CDATA[Reply to A GitHub for maintainers - Giving dependencies the same treatment the fork got on Sat, 02 May 2026 18:11:20 GMT]]>@djc I think it could be ran cheap enough, especially if it’s not ran on every commit

]]>https://board.circlewithadot.net/post/https://mastodon.social/users/andrewnez/statuses/116506327794821164https://board.circlewithadot.net/post/https://mastodon.social/users/andrewnez/statuses/116506327794821164Sat, 02 May 2026 18:11:20 GMT<![CDATA[Reply to A GitHub for maintainers - Giving dependencies the same treatment the fork got on Sat, 02 May 2026 18:01:35 GMT]]>@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.

]]>https://board.circlewithadot.net/post/https://hachyderm.io/users/djc/statuses/116506289456565629https://board.circlewithadot.net/post/https://hachyderm.io/users/djc/statuses/116506289456565629Sat, 02 May 2026 18:01:35 GMT