Open rubyFeedback opened 6 months ago
Hi @rubyFeedback,
We expected that the time constraint might need adjusting, so thank you for reaching out. The goal is to cause as little disruption as possible to the community and the maintainers while setting boundaries on acceptable use. We chose these specific constraints to allow most yanks, but to require communication with our security team when they are likely to have a large impact on the users of rubygems.org.
The decision was made by the Ruby Central Open Source Committee. The aim of the committee is to ensure that we act in the best interest of the community as a whole.
I'm happy to explain the reasoning behind our decision. Our logic is as follows:
Old versions are known and even expected to have bugs. That's the purpose of patch versions. A single maintainer choosing to delete publicly distributed versions breaks untold numbers of people and forces an immediate halt to their processes. Instead of allowing people to go through normal upgrade processes, a maintainer can unilaterally dictate the breakage of any package they maintain. We ask that maintainers include rubygems.org in this decision when their gem meets certain criteria.
We are open to evolving these constraints collaboratively if we are not meeting our goals. For anything urgent, we have a 24 hour on call rotation ready to help with emergencies that may arise.
I understand and appreciate the efforts being made for the betterment of the community. However, I wish we had received a heads-up before this policy was implemented. As maintainers, we need some control and oversight over our work. Some projects go stale, and we don't want to clutter our accounts with old gems that are no longer being worked on.
There should be a grace period to clean out our accounts, similar to the process before this policy was introduced. A better approach could be to mark a project we wish to yank completely. If there's no reasonable objection with an explanation from a community member using the gem within 90 days, we should be able to freely remove the gem.
@bradpotts if you want any gem being yanked or deleted, just reach the support. Usually there is no problem to make it happen.
@Simi, thanks for the suggestion. I contacted support on July 13th, confirmed a safe list of gem removals on the 18th, and followed up on the 25th, but they’ve been silent since the 18th.
While I understand rubygems.org is a big site and a free service, the process is slow and requires multiple proactive follow-ups. Without a ticketing system or updates, it's hard to track progress, or if they're attending to my request.
They should reconsider how they handle small or insignificant gem removals with no dependencies. Perhaps these small projects can be yanked without involving support, while larger or gems with dependency from other gems follow the 30-day rule.
@bradpotts sad to read about your bad experience. There were some changes in service RubyGems.org uses (there is actually ticketing system behind), maybe it is related. I'll ensure your case will be picked as soon as possible.
thanks for clearing everything up appreciate it.
Versions published more than 30 days ago cannot be deleted. Please contact RubyGems support to request deletion of this version if it represents a legal or security risk.
^^^ just had that now when I tried to remove an older version of a gem I maintain that had a few bugs.
Could someone let us know who made that decision?
I do not want to be associated with old code that I no longer maintain, so the only option I now have is to remove my account at rubygems completely, rather than receive emails asking about old, buggy code here; and "contacting" xyz random person at rubygems.org is a no-go, not sure who at rubygems.org had that strange idea. Before I do so, I'd like to know whether that decision will be reverted or not. Either way is fine for me but I would like to know.