[Lerc]

Would you hold off on fixing a security vulnerability if it caused a limited regression?

Regressions should be fixed expediently, but if you apply the criteria "need to not happen" they are literally blocking issues. They could then block security fixes.

[izacus]

Which part of security fixing demands thoughtless generation of code slop without regression testing though?

I worked on major OSS projects and we never just blindly pushed out untested poor quality code for security fixes since that adds WORSE security regressions.

[Lerc]

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'

[overfeed]

> ...if it had been thoroughly tested was shown to have certain regressions but no worse security regressions?

You'd have to test to know this, and there is no evidence that tridge did this regression testing - or ask Claude to find possible regressions caused by proposed changes. If tridge did test for regressions, but chose not to document the regression, then it's still negligence, regardless of the tools pr processes involved.

[Lerc]

Are you saying that it is irresponsible to test for regressions and to not document the ones you didn't find or that you think it is reasonable to expect regression tests for every possible regression?

[overfeed]

No, I did not say any of that.

[Sacho]

What were you trying to say? Because what you wrote is what parent responded to.

> there is no evidence that tridge did this regression testing

What evidence would you be looking for? New tests, like the ones added in the AI-assisted commits? What other evidence?

> If tridge did test for regressions, but chose not to document the regression

Presumably you weren't trying to imply here that tridge found a regression and decided to ship the code anyway; so parent went to a natural assumption - do you think testing for regressions finds all regressions?