08:20 <willcl-ark> maflcko: Would there be any downsides to pruning the fuzz inputs say twice per release cycle? Some of the fuzz CI runtimes are getting quite long e.g. https://willcl-ark.github.io/bitcoin-core-ci-stats/graph/execution/#MSan,%20fuzz

11:08 <fanquake> Does anyone use openrc? Might want to review: #35978

11:08 <corebot> https://github.com/bitcoin/bitcoin/issues/35978 | contrib/init: fix unused variables in openrc script by jpk68 · Pull Request #35978 · bitcoin/bitcoin · GitHub

11:28 <dergoegge> https://gist.github.com/dergoegge/84a77eb85d90ca5cb70c60481c3e8f40 would be curious to hear thoughts on this

11:50 <fjahr> I think you mean "decrease the likelyhood" in bullet 4?

11:54 <fjahr> Just fix it all doesn't seem workable if we want to still make progress on bigger projects and not lower the level of human scrutiy on each change, so I don't think that is acceptable. I would guess that moderation of these kinds of reports could be mostly automated though by checking new issues against existing issues that were closed with won't fix (or issues in the public repo you mentioned)?

12:18 <dergoegge> Yes, decrease

12:51 <_aj_> dergoegge: hot take: have the AI prioritise them, and look through open issues/PRs for duplicates. any that are already reported, add any additional info project loupe found, and/or a generic +1. once that's done, make sure there are open issues/PRs for the five highest priority. as those get resolved, open new issues for the new five highest priority until they're all fixed/not-a-bug'ed.

12:56 <_aj_> dergoegge: (prioritse == rank in importance from 1..100, not just "low/medium/high/critical". maybe should have a 2d severity covering both difficulty-to-trigger/impact-when-triggered)

13:58 <sipa> github down for everyone?

13:58 <brunoerg> yes

14:02 <_aj_> only mostly dead, which means slightly alive

17:13 <nkaretnikov> _aj_: agree. the only question is who is going to pay for all these tokens, especially if the volume grows over time

17:15 <nkaretnikov> also, it would only matter if ai is able to get these into a mergeable shape, so that when a maintainer opens one, it’s only necessary to click on the merge button most of the time

17:17 <nkaretnikov> another thing you could potentially do is to add a claude.md or an equivalent file that would be picked up by ai (that these reporters use) that would instruct on what issues not to report. this will hopefully prevent people from submitting the same issue 20 times that you have no intention of merging anyway

18:43 <achow101> dergoegge: I think we should just open issues for them, even if they never get fixed or get closed as won't fix. Reporters need to be looking through previously reported issues before opening a new issue and stop opening duplicates.

18:59 <jonatack> achow101: agree