PointlessOne 
So #bundler added support for cooldowns.
https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-be-vetted.html
Aside: This feature is mostly developed by Claude. I haven't reviewed the code. Maybe it's fine. Maybe hsbt did actually read, understood, and guided all the code generated here. But in any case it's kinda depressing that even #Ruby, "a Programmer's Best Friend" language with goals like happiness and fun is outsourced to AI that neither can have fun, nor can be happy, nor have friends.
Anyway, I don't fully get the appeal. My main point of contention is that it's a solution trice removed from the problem.
The problem is "supply chain security". Sometimes malicious packages get pushed to package registries. It's not that much of a problem if the package is completely new as it doesn't have users yet and people tend to be cautious about new packages. But it's a problem for established projects that get compromised. They have a lot of users and many people depend on them. So a compromised package with lots of users needs very little time to get installed all over and execute its evil plots.
Someone noticed that it doesn't take much time for people to notice that something's not right. Just days, even mere hours. And they came up with a solution: what if we don't install packages right as they get released but wait, say, a week?
It's a self-defeating strategy. Imagine everyone does this. No one installs packages until they get a week old. How will people know if something's not right if no one's using the package?
The whole thing depends on someone noticing that something's not right. But the fewer people use the package the lower the chance that someone will notice. Package cooldowns work great for the small fraction of users in the beginning. But the closer cooldowns adoption goes to 100% the less effective it becomes.
It also implicitly relies on someone noticing an issue. And someone investigating it. Someone needs to a) install the package, b) notice the issue, c) investigate it. None of this is guaranteed by cooldowns.
A more explicit strategy would be that every package needs a certain amount of reviews from the users to become generally available. So every package upon release becomes available on the index for review. A package manager notifies users that a new version is available in staging and they can help it move along. The package is not available for automatic installation. There's a diff to the previous version that people can review. This is my first idea and it certainly can be improved but, as an example… Users who reviewed the package and approved it can install it right away. The package becomes generally available once a certain amount of reviews came in. E.g. 0.5% of weekly downloads, or 5, 10, 20, etc. approvals from highly trusted well known people in the community who are not involved in the project.
As opposed to cooldowns this explicitly depends on actual reviews. Unlike cooldowns, wider adoption improves efficiency: more reviews—faster availability. It also promotes the "best practice" of actually reading the code you install.
Now, to make it a thing I need a catchy name for it. I'm taking suggestions.
Hacker News
news_kr
Giménez Silva Germán Alberto
bot
