Take stale gems offline then delete them

[mslinn]

Problem

rubygems.org has many stale gems that have not been updated in 10 or 20 years, and are not downloaded by humans.

Describe the solution you'd like

1. Attach a warning to the description. Example:
   **WARNING** This stale gem has been flagged for deletion. It has not been updated since 2001-01-01, when Ruby 1.6 was current. Unless this gem is updated it will be taken offline on YYYY-mm-dd and deleted on YYYY-mm-dd.
2. Notify authors by email; if email bounces back, add that to the description Example:
   Email sent to author(s) bounced back on YYYY-MM-dd
3. On YYYY-MM-dd, take the old gem offline. This means the web entry would still be visible for 3 months, but requiring it would fail, and the description would read
   **ERROR** This stale gem has been taken offline. It has not been updated since 2001-01-01, when Ruby 1.6 was current. Unless this gem is updated it will be deleted on YYYY-mm-dd and there will be no trace of it on RubyGems.org after that
4. On YYYY-mm-dd remove all reference to the stale gem on RubyGems.org.

Describe alternatives you've considered

I am unaware of anyone discussing this publicly.

Additional context

I have not specified the time intervals between dates. One possibility is that 3 months elapse between scheduled events. This should be discussed before implementing.

[simi]

@mslinn hello. Personally I don't see any problem with hosting old gems on rubygems.org at least for archiving purpose. This could be part of some kind of bundler check if welcomed. Currently it can be implemented as bundler/rubygems plugin if I understand it well. Anyway I think this kind of proposal would make sense as a RFC. Would you mind to open this as a RFC at https://github.com/rubygems/rfcs?

[mslinn]

Not interested in that level of ceremony.

[HamptonMakes]

I'd love to see this!

I was trying to create a new project that would be distributed on RubyGems and every decent name I could think of was currently squatted by some project from 12-15 years ago that's been long forgotten and never 'really' went into use.

It's one of the complications of being around this long!

I might see if I can work on an RFC to spur a discussion.

[rubyFeedback]

I was trying to create a new project that would be distributed on RubyGems and every decent name I could think of was currently squatted by some project from 12-15 years ago that's been long forgotten and never 'really' went into use.

This is indeed a problem. For instance, I created offline a new gem, where the toplevel namespace is Web.

Aka:
module Web

Unfortunately that name is already taken; and the gem was last updated 12 years ago.

https://rubygems.org/gems/web

I think there has to be some kind of transition. One problem is that ruby does not have true ownership,
that is everyone can own this namespace and modify it willy-nill. In most cases it is not a problem, but
in some cases I think more flexibility would be useful, such as HamptonMakes gave in his use case.

I think it would be best to actually start this discussion on ruby core, even IF it originated from people
who are working on gems. Ruby could adopt some kind of lazy ownership model, where ownership
is just tracked only, as a first step at the least. And then this may already help solve issues. For instance,
people could do something like this:

gem install web --owner=joe_the_gun
gem install web --owner=donald_the_duck

And so forth. This is not 100% solving the issue of "strong namespaces", but it would give users a way
to specify which gem to use. And rubygems.org itself could also allow hosting multiple different gem
names. Github kind of does this, since every owner has a corresponding page attributed via the name,
so we can have as many projects called "web" as possible.

Independent of the above, rubygems.org could consider transferring the ownership of old gems, and
perhaps rename such gems automatically, e. g. put them into an archive/ or prefix via archived_ or
"ancient_" or something like that.

[simi]

@rubyFeedback RubyGems.org definitely needs namespacing, but it is super hard to introduce in safe manner 🤔.

[mslinn]

A quick housecleaning would be significant and easy. Less is more.

[simi]

Any idea about housecleaning rules/constraints?

[mslinn]

This post is merely meant as a list of potential TODO templates, it does not define quantities or values.

I suggest the first step is to define acceptable collateral damage; no change is ever 100% perfect, and it is foolish to try to be perfect. Perfect is the enemy of the good (enough). A brief discussion should provide a definition and quantification of acceptable collateral damage.

• Gems that have authors whose email is no longer valid, and have had no activity for U days/months/years should be delisted.
• Gems that require ancient, obscure ruby versions should be scrubbed. The V versions of Ruby that will be supported should be publicly listed for W days, and an email should be sent to everyone possible regarding the pending delisting.
• Gems without code should be delisted immediately.
• Gems that do not function and have not been updated for X days/months/years should be delisted. This process of assessing whether a gem is outright junk might be a manual process, or perhaps an automated, or semi-automated process. Simple bug detection is out of scope. If a gem cannot be loaded, for example, or it does not define anything when loading, then them thar gem is wut we call busticated.
• Gems without documentation (no README, or working URL for a website, etc) should be delisted immediately after Y days/months/years of inactivity.
• Gems that are pending delisting should have a publicly visible notice on their RubyGems page.
• Authors of gems that are pending delisting should be notified by email.
• Once delisted, a name should not be reassignable for Z days. During this time, a delisted gem could be reinstated.
• Provide a way and a policy for new maintainers to take over delisted projects?