I am discussing outcomes, not methodology.

The methodology describes the effort you may be putting into something, The outcomes are about what results are you prepared to accept.

Would you ship an update with a security fix if it had been thoroughly tested was shown to have certain regressions but no worse security regressions? Would you refuse to fix the security issue until you could do so without any degradation?

It's clear that people can and do accept regressions for security updates. Spectre mitigations cause performance regressions. SharedArrayBuffer got taken away for a while. Being absolutist about things seldom helps.

I agree due care should be taken where possible, but I'm also prepared to accept that mistakes can happen even when people have worked diligently to find issues.

Since you have worked on major OSS projects. Have any of them shipped regressions unintentionally? Right now that is the only thing we have to go on, that these things happened. The degree of care taken is an unknown, as is the degree of LLM involvement. We might know more in a week or two.

If you want to condemn something based upon what might have happened you can specifically state what you think shouldn't happen, and that will stand regardless of whether or not it applies to the current incident.

Obviously "Thoughtless generation of code slop without regression testing" is unacceptable, but that is because the conclusion is written into the statement by saying "thoughtless" "slop" and "without regression testing"

If tridge says 'I gave it thought, I don't agree that it is slop, and I did regression testing' then you have nothing further to complain about, because the incident does not fall under the criteria you specified.

It's saying 'things that are bad, are bad'. The defence is to say 'well, this isn't bad'