Cassandrichdalias@hachyderm.io
Oct 27, 2026, 4:28 PMReplies
Oct 27, 2026, 5:56 PM- Cassandrichdalias@hachyderm.ioOct 27, 2026, 6:05 PM
@lanodan @lattera @mcc @linear Yeah. If they want to go back and strip out the slop taint in tests, they can just rm all the affected tests. Zero impact on actual functionality. And until then, the potentially-dangerous code doesn't end up running on users' machines. Just git forge CI infrastructure. 🙃
- Cassandrichdalias@hachyderm.ioOct 27, 2026, 6:21 PM
jeremiahjeremiah@tldr.nettime.orgOct 27, 2026, 6:31 PM@dalias hardcore blackbox testing.
Hmm. I had not considered moving them all the way out of the repo. That's really interesting
- Oct 27, 2026, 6:48 PM@dalias @lattera @mcc @linear I think it can make sense to still have tests against private interfaces, for example to avoid lengthy tests or hacks like test-only code.
That said I think anything not-cleanly-foss (or other license annoyances) belongs into a separated repo and ought be entirely optional.
Which goes even beyond tests as most OS projects will end up with firmware blobs as well. 
Oct 27, 2026, 6:58 PM@lanodan @dalias i think the main reason for tests in the same repo is just the convenience to run them against your WIP branch
having to do the whole install to your live process to run tests, or setup cross project build systems, is kinda painful (and for the install, could risk breaking your system for a core package, happened to me w/ openrc a few times)
Oct 27, 2026, 7:07 PM- Oct 27, 2026, 7:13 PM
Also many of the gcc tests are only compiled and not run tests (this is even more true of the ones created by LLM it seems).
Plus ones reported via bug reports are small self contained testcases which have been audited when writing fixes for it, I am not sure if those are even less cared about.Yes a compiler might be a special case for testcases unlike say a library.