I was reading the blog of the "reqwest" author and one of the sub points was this:
The odd name is an unfortunate consequence of being late to the party. The request crate is effectively abandonware. I’ve tried reaching out to the author in various ways, but he seems to have disappeared from the internets. The requests crate (with an ’s’) also exists, but does seem to be actively developed. http://seanmonstar.com/post/153221119046/introducing-reqwest
This is bad. Bad for developers as it makes it difficult to remember which crate you should be using, bad for the community as it lets people abuse the package manager, and bad for the individuals who create crates because it puts a requirement on them to always be active and doesn't allow them to abandon work if they don't want to do it anymore.
I want to propose two things:
Add a way in Cargo to "give up" your crate name. Essentially this will delete all versions already on it and make the name available for others to claim.
Also add a way to open a ticket to gain ownership of a crate name. That crate has to have very few downloads over some time period (say 6 months) and have no new updates. If either of these are true, you can request to gain ownership. If you do, all maintainers will receive several emails over a couple of weeks which will allow them to keep the name. If not, the name will be transfered.
Under very rare circumstances, it should be possible to transfer a name for the good of the community. Such a name would include the "request" crate if that became necessary.
I have been the cause of this problem before, where I created a crate called rst for my requiremrents tracking tool, forgetting that it was a common name for the ReStructured Text format. In my case, I gave the name over -- but it doesn't always turn out that good
Advantages
allows crates that are core to the community to be maintained in any eventuality
allows for names that are common within other communities (i.e. python) to be used within the rust community, making it easier for newcommers
reduces confusion within the community (like having 3 names for the request module but only one is maintained).
without some process in place, we are susceptible to what happened to node.js -- in particular cargo DOES allow the maintainer to unpublish versions (maybe this ability should be removed? Possibly separate question)
Disadvantages
depending on implementation, may increase strain on crates.io maintainers
could cause strife within community, especially if someone feels that the process is unfair
time limits are difficult to determine with any evidence-based approach, decisions may be somewhat arbitrary.
There is another problem here, which is what if a maintainter of a community critical crate gets hit by a bus? As sad as that is, we as a community need to be able to maintain our core libraries and we need a process for new maintainers to take over.
The bus problem is a valid issue, but removing crates from the registry (in order to replace them with another crate) means you can't guarantee reproducible builds of other crates depending on the original crate.
I do not think we need any policy for transfering the ownership of crates in cases where the crate's owner or their estate has not consented. Adjudicating what it means for a crate to be "abandoned" or "the good of the community" is not crates.io's responsibility.
what about option 1 -- allowing crate owners to abandon their crate?
The first name I used for my requirements tracking tool was "rsk" and now I am the owner of that crate name even though I don't intend to develop there. None of what I published is really useful to anybody. Shouldn't I be able to give up my crate?
you could leave the original versions and require new development to do a major version bump. Would that be acceptible?
shouldn't it be the community's responsibility though? Shouldn't the community decide these things?
Well, I definitely don't think its for the good of the community to take peoples' names away "for the good of the community." We've already seen a prominent example of how that can make people feel & react earlier this year.
I think a mechanism for transfering ownership of a crates.io name is a totally reasonable feature for crates.io to have, but that the maintainers of crates.io should not be asked to shoulder the responsibility of taking peoples' names away.
For an outside example, Fedora has a policy for non-responsive package maintainers. However, distro packaging is a lot more communal than crate ownership, so their three week period is probably way too short here. Still, I definitely think it would be good to have some sort of formal policy like this for crates.io.
After reading this blog post I decided that having this ability is simply not worth it. It opens up a whole can of worms that we simply don't want to deal with. We will NOT bow to corporate lawyers, or really anyone, regarding package names. Furthermore, people can come up with their own clever names for packages.
I would like to change teh proposal to the followng:
all versions are frozen and can't be unpublished (remove the ability to unpublish)
a way to "remove ownership" from yourself -- possibly we want to put this in some kind of pool where new maintainers have to be approved by a community selected group? (I'm worried about rogue maintainers causing security vulnerabilities).
an unmaintained period with notifications to keep ownership -- after which it automatically goes into the same pool as "removed ownership" but new versions have to have at least a minor version bump. The unmaintained period should be very long.
Outside of this there is no method to gain ownership.
Thanks for sharing the Fedora example. Does anyone knows if other groups have similar policies? Ruby gems, pypi, npm, etc -- it seems like the issue discussed here would have come up in those communities as well. Can their experiences offer guidance to the rust community?
npm had a policy where the registry was mutable and at the whim of the company; that led to the aforementioned incident known as "left-pad". They've since changed their policies to be almost identical to ours. (They have a small grace period where you can unpublish something in the first 24h if nobody else depends on it)
Huh, I didn't realize that yanking allowed you to still download the version -- awesome!
It would be great if we could get a group of volunteers to hold abandoned names for the community to use. A simple github group would do. I think this is actually all that would be needed to solve 98% of the potential problems here.
We would want:
the group to be created on github
crates.io documentation to call out how to abandon a name (just add this group as owner)
crates.io docmentation on how to claim a name (just open an issue on the git issue tracker)
I would be willing to be the original maintainer of such a group, although I think it would be good to have it as part of the rustlang github group. Feedback would be welcome.
I've already abandoned my own crate (rsk) and have a general process defined for both people that want to abandon their crate and those that want to help out. I hope to automate much of this in the future.
Any feedback, help or abandoned crates would be great!
Next steps:
get some users, both volunteers and abandoned crates
open an RFC to add this to the crates.io documentation.
