Programming

You most certainly are, use a different metaphor/descriptor.

Also, having critical software depend on one guy is not safe. We should avoid that. If critical software depends on one guy it should be phased out.

Here are the percent of commits from the top committer in each repository you mentioned, as well as rsync, over the last 3 months:

• rsync: 99.0%
• restic: 93.2%
• rclone: 87.5%
• union: 82.9%
• syncthing: 74.4%

As you can see, each of this projects depends heavily on a single person, though to a lesser degree than rsync. That's just the nature of most open-source software.

Note that I excluded dependabot commits from the calculations and counted Claude commits as the lead developer for rsync

The trouble with some of those projects (e.g. unison and sun thing) is that they don't solve the same problem, not really.

A rewrite with modern tooling would be better done if it was incremental.

I don't know the degree to that, but bugs do happen occasionally either way as long as there are changes. In the article, they explain why the changes are necessary. Prioritizing security over no-change-stability seems reasonable and warranted.

One shot rewriting the whole test suite

tridge's blog post makes it clear that this was not "one-shotted" at all.

You should read the whole thread

I regret reading it; I'll assume in good faith that it wasn't LLM generated but it is ironically as confidently wrong as if it were.

It almost (and should have) lost me when it started by quote-agreeing with someone else saying "rsync was basically done until the maintainer discovered vibecoding" - no, pay attention, it was not "basically done", there were/are a mountain of CVEs!

But then this got my interest:

This does not “translate tests into pytest” or a unit testing framework, it writes its own testing framework where tests are whole python scripts that redefine basic test functions in every script. Surely there would be a single way to “run rsync and get the results” - nope, well, there is, but then every test file will randomly redefine its own _run_and_capture function.

tridge says he has used pytest on other projects and had good reasons not to use it here; I'm inclined to believe him.

But the notion of every test defining its own way to invoke rsync sounded like a valid criticism, and an easy one to verify, so I checked: It turns out that there is in fact a common run_rsync function which is used by the majority of the tests. One test defines its own _run_and_capture function (which differs in that it writes the output to a file, for reasons I didn't investigate), and it looks like a few others invoke rsync other ways, but the majority of them use the common function.

So, that rambling thread's sole concrete criticism of rsync's new python tests turns out to be false.

I write python code for a living. There is no way to sugarcoat it, the new unittests are slop. There already exists a good writeup of why, which I’m going to quote here:

They are not unit tests, they are integration tests. Which in my experience makes unit-testing frameworks like pytest a poor fit. I've also had to write my own framework, for that reason, despite preferring pytest for unit-testing.

The author also greatly exaggerates the amount of code duplication: They claim that "tests are whole python scripts that redefine basic test functions in every script", but in reality it is less than half of the tests that even define their own functions.

Most basic functions are imported from a shared module (rsyncfns.py), and when they aren't it's mostly because the code needs to do something different. From what I can see, there is some code duplication that could be moved to the shared module, and some code that could be refactored, but it's a modest amount