So? May main point is: Which commits actually broke the functionality? Going from 3.4.3 to 3.4.2 to test should be easy for anyone affected and would have been more helpful than this rant.
I'm not defending bad slop commits, especially for such a long running project but the tribal Fediverse outrage whenever LLMs are involved is often just lazy and uninformed.
> NOTE: This also affects backported rsync versions when they're used on the Receiver:
> Debian: 3.4.1+ds1-5+deb13u3 / 3.2.7-1+deb12u5 / 3.2.3-4+deb11u3
> Ubuntu: 3.2.7-1ubuntu1.4
It's pretty shitty to accuse someone of vibe-coding without having any idea what their LLM-assisted development process is. Let's do better, please.
So? May main point is: Which commits actually broke the functionality? Going from 3.4.3 to 3.4.2 to test should be easy for anyone affected and would have been more helpful than this rant.
I'm not defending bad slop commits, especially for such a long running project but the tribal Fediverse outrage whenever LLMs are involved is often just lazy and uninformed.
To quote this PR: https://github.com/RsyncProject/rsync/issues/928
> NOTE: This also affects backported rsync versions when they're used on the Receiver: > Debian: 3.4.1+ds1-5+deb13u3 / 3.2.7-1+deb12u5 / 3.2.3-4+deb11u3 > Ubuntu: 3.2.7-1ubuntu1.4
Figuring out which commit broke what functionality is not something you can expect users to do.
No, but that's probably a required skill to have before you initiate claims as to what the cause of the loss of functionality was.
If you're willing to build from source it's not particularly difficult with git bisect