"dependency cooldowns" versus "upload queues"

Thanks for stripping the pseudo-moral considerations out of this, it helps see things more clearly.

https://calpaterson.com/deps.html

> Frankly, dependency cooldowns work by free-riding on the pain and suffering of others. Fundamental in the dependency cooldown plan is the hope that other people - those who weren't smart enough to configure a cooldown - serve as unpaid, inadvertent beta testers for newly released packages. If there's a problem, those poor saps get hacked, everyone notices that they got hacked, and the problematic package/executable is yanked before the dependency cooldowners' thresholds are reached.

This is ridiculous. You could (try to) forbid "stable" releases with the same line of reasoning! It's the exact same thing: sticking to existing bugs while waiting for others to find new bugs. But for some strange reason that does not shock anyone?

There is no "People should just...", never has been. The only way to stop people using a "bad" system is to offer a more appealing system - which to be fair, seems to be exactly what is proposed in the rest of the blog. Too bad it starts with the pseudo-moral stuff.

The reality is:
- Open-source projects get released and distributed freely in any way they want
- Distros and packagers consume versions and releases at any random pace that suit them.
- Users upgrade at any pace they feel is best for them.

Each "consumer" is free to decide for themselves and that freedom is more than fine - it's one of the essential software freedoms. That pace ALSO depends of course on release lifecycles and distribution systems offered, which make up some sort of consumption "API". Telling people that they are "using the API wrong" is mostly futile, always has been. If some API is used incorrectly too often, then it is a bad API and yes a better one (upload queues? something else?) must be put in place. It is unproductive to blame consumers (or anyone else really) for doing the "wrong thing" as long as only "bad" systems are available.