[SkeuomorphicBee]

No, it didn't exist (outside Google). Debian testing is not a rolling release because it is not a "release", it lacks internal coherence. As the article mentioned, testing packages are built in unstable and then simply moved to testing individually, with no regard to moving all the build dependency chain together. So you end up with packages in testing that were built using packages that are not in testing yet.

Edit: also testing lacks timely security updates, they don't bother to cherry pick security patches for testing and instead just wait until the new secure version make is way thru unstable.

[viccuad]

That sounds like moving goalposts: the OP mentions Arch's rolling release. And Arch doesn't rebuild the dependents when a package gets updated.

On the point of Testing lacking timely security updates, it's fair. But I invite you to compare the timelines with other distributions (including from corporate backers), and you will realize that their manual testing takes even more time.

Plus, you always have Debian Unstable. And apt-listchanges and apt-listbugs work fine in Unstable. It's the same experience: you get notified of serious bugs before upgrading, you get to pin packages and the pins are automatically lifted with the fixed version.

[nemetroid]

> And Arch doesn't rebuild the dependents when a package gets updated.

That’s not the point they argued, though. According to the comment you replied to, given version X of package A built against version Y of package B, Debian testing might contain package A version X but not package B version Y.

As far as I know, this situation does not occur in Arch.