what I will say is this. there are pieces of software that are frankly "mission critical".

for example, pkgconf, as a key component of most build toolchains, cannot have regressions because those regressions will reverberate throughout the entire "software supply chain" in the form of build errors. it is a mission critical piece of software.

this is why as lead maintainer of pkgconf I have implemented a number of policies and initiatives to reduce the likelihood of software errors and promote correctness in pkgconf as part of the pkgconf 3.0 work.

these initiatives include banning LLM contributions, requiring DCO signoffs on commits, refactoring the codebase to remove entire classes of vulnerability, improving the quality of the windows port so it is equivalent to its unix counterparts and reimplementing and expanding the test suite from scratch.

why? because every single thing I listed reduces the likelihood for regressions.

rsync, like pkgconf, is used at all times of the day, all around the world. I try to visualize the scope to which pkgconf is used and it is just not possible.

rsync is the same way: everyone is using it somehow, either to back up their data, or to mirror data from one machine to another. there are numerous utilities which make use of it somehow to provide functionality.

a regression in rsync is even less tolerable than a pkgconf regression: if you have errors in rsync, they can potentially cause data corruption or loss.

but rsync goes in basically the opposite direction from pkgconf: it embraces LLM contributions. it also has had several regressions since doing so.