I'm not sure there's anything novel about that approach - it's how I've addressed issues quite commonly when assigning them to team members. If you don't prime your preconceived notions on your coworkers(or AI in this case) and let them do their own evaluation from scratch, you can find gaps in yours and their understanding much easier.
> The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding
Hi fao, the issue you linked starts with:
> Rsync 3.4.3 and newer is AI slop, and currently has several open security vulnerabilities and other critical bugs (including some link-related ones) caused by said AI slop:
It then proceeds to link to multiple functional regressions caused by (theoretically) fixes to security vulnerabilities.
This took me about 10 mins to review. It seems that the person who created the issue did not bother to spend 10 minutes to check his own work. Is this "vibe reporting"? What should we say about the irony of employing "human slop" to trash "AI slop"?
Further ironically, the "aggregate of bugs" in void-linux included an issue that was not even about rsync. More "human slop" that you are happy with?
Their mission critical software has bugs in it - security issues, which the rsync maintainer is trying to fix. In his attempt, he introduced regressions*(maybe - because some of the reported regressions list exactly the security issue that is being fixed as their use case...). This happens every day to thousands and thousands of software projects. This is why we have pinned versions, release schedules, different release philosophies...none of this is new.
I don't understand what novel problem you think you've uncovered here.
> It's like people telling you they will paint your house for free, even though the color of your house is perfectly fine
You are perfectly capable of saying "No, I like the color of my house already". Just pin rsync's version. This isn't some esoteric mechanism, it's standard practice.
If you were actually willing to charitably engage, tidge was working on fixing security bugs - your house had holes in it already! Your choice was to say I'm fine with the existing holes, or yeah please try to fix them. Unfortunately while fixing them he introduced some new ones, but hey, that's the nature of software development - sometimes you introduce new bugs when fixing old ones.
Again, this isn't some esoteric happenstance. It's so banal it must happen thousands of times per day across many other maintained projects.
If Rsync is complete software, why aren't you pinning the version and avoiding any problems with updates?
Perhaps there's people that don't consider it complete software; they can bear the burden of the new releases while you stay on the old and complete one. This has been normal software release and use practice for decades. Whole Linux distributions are built around different philosophies on software releases.
And yet you're making an argument as if this is something novel...
The bugs were introduced because rsync had security issues(i.e. bugs) in it, presumably written into the code by humans.
It's really baffling to see so many people in this thread maintain the position that somehow software was clean and pristine until AI touched it with its evil.
Please try to at least put some sort of constructive argument forward, for example - I don't like AI because it might introduce more bugs than a careful human reviewer. Then we could discuss why a single maintainer is responsible for rsync and how they should handle the pressure of keeping it up to date - should they just stop making further changes, should they look for tools that might help them?
(By the way, if your position is that rsync was perfect before AI got its hands on it, you have a clear solution to all your problems - simply do not update to any newer versions)
Either way, move away from this absolutist nonsense that has no bearing to reality.
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?
This would create a lot of noise for the regular readers of his blog, who already know the definitions of these terms. The terms are not even obscure. This is also a blog, not a piece of technical documentation.
What makes you unhappy about this process?