[Policy change / discussion] Decide when a gem became inactive #3048
rubyFeedback
started this conversation in
Ideas
Replies: 1 comment
-
This is exactly solved by namespacing. There is no need to re-invent the wheel again. Feel free to contribute to rubygems/rfcs#40. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hoi there rubygems.org maintainers,
This is a bit of a suggestion or encouragement to discussion, not so much a typical issue request.
I'd like to ideally get some people to do pro or con on the proposal as such.
So, let me explain the background, which includes the rationale for this proposal.
I have an old gem called "extracter". Recently, though, I considered renaming it to
"archiver" instead. In the past "extracter" would extract .zip files, .tar files and so
on, all using "tar" mostly, sometimes "zip" or p7zip or how it is called on windows.
But, I also have use cases to create archives - zip files, tar.xz and so forth. So
the name "archiver" makes sense to me: I want to work on archives of software
files, that is extracting archives, and creating archives (usually .tar.xz).
I'd adopt archiver as name, probably, and abandon "extracter" so someone else
can use that namespace since I no longer have a use case to use that name,
then.
The problem is there is already another gem called archiver:
https://rubygems.org/gems/archiver
I believe via bundler and github we can avoid this limitation, right? We can just
install from a github repository.
On rubygems.org, though, people can hold namespaces. Ideally I'd love if we
can have several same-named projects, and then specify which one to use.
But this is NOT what this proposal is here about.
This proposal is more about the question HOW LONG should inactive
developers and inactive projects keep the namespace.
Have a look at archiver: https://rubygems.org/gems/archiver
Last push in December 2012. That's almost 10 years.
Is it safe to say the owner MAY have abandoned it?
Furthermore only 14.000 downloads. That's not much either.
There are even older projects, inactive ones, going back to about
2006 or so.
Can we adopt some policy, to, at some point decide WHEN a project
becomes inactive, and may be up for adoption or replacement?
The old code can be pushed into a local archive anyway and instructions
given how to obtain that code still. So nothing would be "lost" per se.
So this here is mostly about WHEN to decide when a project is inactive.
I can not say a real date line or something, perhaps even 5 years
inactivity is too much. But let's be conservative, say, 10 years of
inactivity should allow others to take over that namespace, and
the old gem becomes archived.
If you do not want automatic removal then perhaps you can tie
it to "reputation" and number of downloads, so people with,
say, 1 million gem downloads in total may have an ok-ish reputation
so they can take over a project. Or perhaps an automatic application
and then someone approves it if you want to take over such a
namespace, but that requires manual intervention which is not
always good - sometimes nobody has time so...
Be it 5 years or 10 years - it's just a number. I'd like to see this
become an official policy, though. As it is right now people get
more options by using github + bundler, if I understand it
correctly, because you are not restricted to any inactive projects
and people can install from there just fine?
My biggest gripe is that "gem install NAME" will only work for
one project. When that project is active then it's ok, but inactive
projects paralysing others who are active should not be
possible. How many of these projects aged +10 years will
suddenly become active? Very, very few.
Beta Was this translation helpful? Give feedback.
All reactions