New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

eRFC: Crate name transfer #2614

Open
wants to merge 6 commits into
base: master
from

Conversation

Projects
None yet
9 participants
@dtolnay
Copy link
Member

dtolnay commented Dec 16, 2018


[RENDERED VIEW]


Summary: This experimental RFC proposes a process by which a designated Rust team member or members could reassign ownership of a crate name on crates.io. The aim is to identify the absolute smallest, most conservative step we can feasibly make from the status quo of crate names that can only be transferred by a current owner. The proposal is intended to address only the absolute most clear-cut situations in which a crate name would need to be transferred. It is not intended to address the situation of name squatting on crates.io, nor as a gateway to eventual more aggressive forced exchange of crate names.

References

@Centril Centril added the T-core label Dec 16, 2018

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Dec 16, 2018

The @rfcbot does not have a team T-crates-io on record and this isn't exactly about the operation of cargo so I have added T-core in the interim. We might want to fix this before a team triages this RFC.

@burdges

This comment has been minimized.

Copy link

burdges commented Dec 16, 2018

I do think this RFC makes sense. I'll point out that crate namespaces can address roughly the same problem, with less manual intervention even than this RFC, but this RFC sounds "more conservative". A namespace approach might go:

  • In some future edition, all existing top-level crate names become deprecated, except for compiler provided crates like std, core, etc. as well as a few crates like futures that integrate tightly with compiler crates. We might extend this to really solid canonical crates like serde and rand, but that creates the same problem, so likely not happening.

  • In this edition, all newly available top-level names become available for maintainers, both organizations or individuals, who must first demonstrate control over some relatively limited name resource utilizing roughly sane name, so a DNS name, github or gitlab user or organization name, stackoverflow name with reputation over 1000, or similar. We’d verify these conditions automatically to minimize the cargo team’s workload. If you cannot satisfy such an automatic condition then you may request a top-level maintainer name manually with a pull request on some cargo-requests repository, which provides a forum for objections.

  • We expose only the lower level crate names to rustc, not the maintainer name. As a result, we should only need to edit Cargo.toml files for the new edition, meaning no changes to actual rust code.

@fbstj

This comment has been minimized.

Copy link

fbstj commented Dec 16, 2018

is it worth explicitly mentioning in the Experiment section that "burnout"/etc of the Responsible Party is a totally valid reason for closing the experiment? similarly is there an upper limit to the length of time of this experiment, or is it worth stating somehow that if the experiment is successful (in that "not too many" renames happen or w/e) then a more formal RFC will be written to solidify the practices afterwards?

may be worth writing down what happens to the RFC itself after the experiment is concluded? I can't remember seeing or hearing of what happens when eRFCs are done, do they stay published but somehow marked as "complete" or "replaced" by their resulting things?

@newpavlov

This comment has been minimized.

Copy link

newpavlov commented Dec 16, 2018

Earlier I've published a less conservative proposal, which is similar in spirit to PEP 541. I hope we will move in this direction eventually.

@carols10cents

This comment has been minimized.

Copy link
Member

carols10cents commented Dec 16, 2018

I have added T-core in the interim. We might want to fix this before a team triages this RFC.

Because the libs and moderation teams are mentioned in the rfc implementation, I think they should sign off too. I forget, does rfcbot support multiple team sign off?

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Dec 16, 2018

I have added T-core in the interim. We might want to fix this before a team triages this RFC.

Because the libs and moderation teams are mentioned in the rfc implementation, I think they should sign off too. I forget, does rfcbot support multiple team sign off?

@carols10cents It does; you just add more labels and the bot will request sign-off from all members in the union of all the teams.

dtolnay added some commits Dec 16, 2018

@dtolnay

This comment has been minimized.

Copy link
Member

dtolnay commented Dec 16, 2018

@burdges regarding namespacing: Thanks! I know many people are excited about pursuing a namespacing scheme. I added a note that I think it should be pursued in a different RFC by someone willing to spearhead a namespacing proposal. I acknowledge that namespacing touches on an overlapping set of concerns and conflicts, but I consider the actual proposal to be orthogonal to this RFC in that we may opt to do neither, one or the other, or both.


@fbstj

is it worth explicitly mentioning in the Experiment section that "burnout"/etc of the Responsible Party is a totally valid reason for closing the experiment?

Absolutely, if at any point it seems that a qualified volunteer is not forthcoming, a team could choose to terminate the experiment. I added a note about staffing under Drawbacks. Note that a gap in coverage does not automatically terminate the experiment -- termination would be a team decision based on the negatives of having the process continue to exist without a person behind it, as well as the perceived likelihood of a qualified candidate turning up in time.

similarly is there an upper limit to the length of time of this experiment, or is it worth stating somehow that if the experiment is successful (in that "not too many" renames happen or w/e) then a more formal RFC will be written to solidify the practices afterwards?

may be worth writing down what happens to the RFC itself after the experiment is concluded? I can't remember seeing or hearing of what happens when eRFCs are done, do they stay published but somehow marked as "complete" or "replaced" by their resulting things?

Interesting question! This does need to be agreed upon. I added a note that the experiment will continue indefinitely until terminated or until amended by another RFC.

@withoutboats

This comment has been minimized.

Copy link
Contributor

withoutboats commented Dec 17, 2018

My concern with this RFC is that it will create a lot of work and stress for project members in the future, despite the RFC's best intentions and clear effort to isolate that work and stress to the "Responsible Parties." I think that inevitably, a decision will be made that will cause conflict, and intervention and moderation will be necessary by project contributors other than the "Responsible Party." And we can't close the experiment in advance of this happening, because we can't predict when it will happen.

@dtolnay

This comment has been minimized.

Copy link
Member

dtolnay commented Dec 17, 2018

Thanks @withoutboats, that is an important drawback.

Do any of the following characterize your perspective?

  1. We can potentially make this proposal work as long as the responsibility for oversight is not spread out across so many people; maybe it should be 1-2 teams only.

  2. It will never be possible for the Rust team to arbitrate crate name situations because the potential for conflict will always exist.

  3. It may be possible in the future but we would need to dedicate paid employees to the problem.

  4. It may be possible in the future but this RFC would be counterproductive / not a step in the right direction.

  5. This RFC is a step in the right direction but its scope is so conservative that the problems it addresses are not worth solving like this.

  6. The primary reason that conflict would arise is from decisions being too conservative.

  7. The primary reason that conflict would arise is from decisions being too cavalier.

  8. We can potentially make this proposal work but it needs to lay down concrete guidelines to ensure that decisions are sufficiently conservative.

  9. We can potentially make this proposal work but we would need a well-defined way to escalate conflicts in a way that isolates most of the Rust team from them.

@withoutboats

This comment has been minimized.

Copy link
Contributor

withoutboats commented Dec 18, 2018

It is not currently worth the cost in moderation of bad feelings and conflict to transfer crate names without the consent of their holder, because crate names are not scarce enough right now. I don't see a process solution to the problem of conflict, so from my perspective its a constant cost and the benefits needs to outweigh it.

@dtolnay

This comment has been minimized.

Copy link
Member

dtolnay commented Dec 18, 2018

@withoutboats ah that makes sense. At the same time don't forget the other half of the story which is bad feelings arising from our current policy. Some more questions to understand your perspective better:

  • Are you referring primarily to bad feelings of community members regarding decisions made about their crates, bad feelings of community members when the experiment is terminated, or bad feelings between members of the Rust team when the experiment is terminated? Since you mentioned constant cost, I suspect it may be the last one.

  • What might tip the scales in favor of benefits that outweigh the constant cost? Especially, what do you think it is about the npm or PyPI ecosystems by which their policies are preferable to inaction? Are they running out of names in a way that we are not yet? Would their users be more vocally upset than ours if clear-cut cases were not addressed? Are their teams better adapted to conflict than our team?

  • Do you fundamentally disagree that there is such a thing as a clear-cut situation, like the one (which I claim is) in the Motivation section? Or is it more about borderline cases which may be substantially less clear-cut than that one?

@jonhoo

This comment has been minimized.

Copy link
Contributor

jonhoo commented Dec 19, 2018

I love this proposal.

@withoutboats there have already been cases where the crates.io team has transferred ownership of crates. For example, this happened recently with the imap crate where the previous owner disappeared after creating mattnenterprise/rust-imap#69 in which they specifically said they were willing to transfer ownership. I would argue that it falls under the clear-cut case outlined in this eRFC, and the crates.io team acted on it (after trying unsuccessfully to contact the crate author). That suggests to me that formalizing that process that already exists is a good idea. Maybe @sgrif can comment on this?

One change I'd like to see to the eRFC is a logging clause. Whenever ownership is transferred, I think that action should be logged, along with who the Responsible Party was, who the original author was, and a short description of why the RP decided that the case was clear cut (should be short, because it's supposed to be clear cut!).

And finally, I would be happy to volunteer as a RP. Though don't know if the Rust team would prefer for the initial RPs to be more core people?

@withoutboats

This comment has been minimized.

Copy link
Contributor

withoutboats commented Dec 19, 2018

@jonhoo In the case you cite, the consent of a current owner is very clearly documented (they had made you a comaintainer of the source repo and written that they wanted to make you a coowner of the package), making it very unlikely to cause conflict. The case I am concerned about is one in which the original owner has not clearly consented to letting someone take over the package, which is what this proposal is about.

If the standard for "clear cut" is "a current owner of the package indicated that they want this person to become an owner of the package," then I think this RFC is fine. But I don't think that's the kind of case @dtolnay is considering "clear cut," and its those cases where the owner has not consented that are the new policy change.

Our current policy is that we will not transfer packages without their owners' consent unless they have violated our policies or we are legally required to. Changing this policy to say that we will transfer packages when someone we have designated considers it a clear cut good idea to do so is, in my opinion, an imprudent policy change that would only be justified by name scarcity presenting a real and immediate problem, and I don't think that's the case right now.

@joshtriplett

This comment has been minimized.

Copy link
Member

joshtriplett commented Dec 20, 2018

The crates.io team plans to discuss this after the first of the year. One item we did have consensus on, though: this should definitely be a small team, not an individual.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment