RFC: policy for rust-lang crates

[aturon]

This RFC proposes a policy around the crates under the rust-lang github organization that are not part of the Rust distribution (compiler or standard library). At a high level, it proposes that these crates be:

• Governed similarly to the standard library;
• Maintained at a similar level to the standard library, including platform support;
• Carefully curated for quality.

Rendered

[steveklabnik]

I would like to volunteer for semver. (I would also argue that it does belong under rust-lang, personally.

[brson]

I am also inclined to think this is a rust-lang crate. If you are doing semver in Rust you might as well use the semver Cargo does.

[steveklabnik]

Right, this falls under the 'common interface' kind of thing, imho.

[sfackler]

uuid seems somewhat nice - is there a particular reason to not transfer it out?

[aturon]

@sfackler: I agree; it's just a question of where we're drawing the line. Moving uuid out would be totally reasonable.

[sfackler]

It seems like we should always prefer to transfer to someone who's willing to maintain it, and only use rust-lang-deprecated as a last resort.

[sfackler]

As mentioned above, it's not totally clear to me why we wouldn't want to transfer these to people who are willing to maintain them just like rlibc, semver and threadpool.

[steveklabnik]

I would argue that it's a quality thing, these are the crates (in theory) that just need to be totally thrown out, as opposed to just fixed up a little.

[nikomatsakis]

@aturon

(For nightly releases, we should include the nursery crates as well.)

I am wondering what the motivation is for limiting nursery crates to nightly releases. Is there an assumption that nursery crates will use unstable features (I would think not)? Or just that nightly people are using an unstable compiler, so they are more likely to want early stage libraries? Basically, it seems to me that nursery crates are at least as stable as any other crate on crates.io, and likely potentially more so, so I think linking them to nightly is a bit surprising.

[aturon]

@sfackler

It seems like we should always prefer to transfer to someone who's willing to maintain it, and only use rust-lang-deprecated as a last resort.

One question here is how these get published to crates.io and so on. A danger of transferring ownership in this way is that a previously "official" crate then continues to evolve unofficially, but is published to the same place etc. Whereas deprecating the crate in place allows official maintenance to continue (in a very limited fashion) while of course allowing unofficial forks to evolve more radically.

For this initial batch of cleanup, it's a bit different: none of these existing crates really have "official" status.

@nikomatsakis

(For nightly releases, we should include the nursery crates as well.)

I am wondering what the motivation is for limiting nursery crates to nightly releases. Is there an assumption that nursery crates will use unstable features (I would think not)? Or just that nightly people are using an unstable compiler, so they are more likely to want early stage libraries? Basically, it seems to me that nursery crates are at least as stable as any other crate on crates.io, and likely potentially more so, so I think linking them to nightly is a bit surprising.

It's not that they're limited to nightly -- they're usable within stable as well -- it's just that we only advertise them on nightly. The idea is to draw a clear distinction between crates that we've fully committed to maintain (which is meant to be a strong guarantee of quality and upkeep) versus those we're just trying out. The nursery also coincides with the 0.X series of these crates, so I think it's fair to say that nursery crates are relatively unstable.

Put differently, if we allow too many/too unstable of crates to show up as "official rust-lang crates" we risk muddling the basic message here. I see the "nursery" as playing a role similar to Nightly releases in terms of the stability messaging we want to get across.

[nikomatsakis]

@aturon

It's not that they're limited to nightly -- they're usable within stable as well -- it's just that we only advertise them on nightly.

I think this was sort of my point. :) I guess my worry was that by advertising them with nightly, we will scare users off from using them, and thus they will not get the feedback we want. But I agree that if we want to avoid drawing too many distinctions, it is better to err on the side of things appearing less stable than they actually are. (And, after all, even though code can keep building against 0.3 indefinitely, it won't enjoy bugfixes and the like.)

[brson]

Let's not deprecate time until there is a plausible replacement.

[alexcrichton]

I would claim that any replacement for this crate would be such a large overhaul that this is basically pre-deprecated. We'll still continue to maintain it and fix bugs here and there, and you won't get a warning message or anything when you use it, it would just move to a new location

[brson]

It's not clear to me whether, after this RFC goes through, there will be any crates under rust-lang anymore. Does this reclassify all existing crates?

[aturon]

@nikomatsakis

It's not that they're limited to nightly -- they're usable within stable as well -- it's just that we only advertise them on nightly.

I think this was sort of my point. :) I guess my worry was that by advertising them with nightly, we will scare users off from using them, and thus they will not get the feedback we want. But I agree that if we want to avoid drawing too many distinctions, it is better to err on the side of things appearing less stable than they actually are. (And, after all, even though code can keep building against 0.3 indefinitely, it won't enjoy bugfixes and the like.)

I see; so you were thinking of advertising in all channels, but in a separate "nursery" section? That seems plausible.

@brson

It's not clear to me whether, after this RFC goes through, there will be any crates under rust-lang anymore. Does this reclassify all existing crates?

Yes. This is essentially the first step in a "stabilization" process for the crates, none of which have undergone anything like the scrutiny that std did. Each nursery crate will require at least an RFC to bring it into official rust-lang status.

[SimonSapin]

homu supports using Travis-CI instead of buildbot. We (the Servo team) are using this with a number of repositories: http://build.servo.org/homu/

[Gankro]

Homu also supports aggregating several repos. e.g. this is every single servo's: http://build.servo.org/homu/queue/all

I think all the rust-lang crates should show up in the main Rust homu instance so that those of us that have triage OCD are haunted by them.

[alexcrichton]

I believe this concern is not so much motivated by automation to merge crates but other aspects such as:

• Running all these builds every night
• Platform coverage -- are they all guaranteed to work on 1st tier platforms? Second tier? Do we have automation to prove it?
• Do we gate releases on these crates working? How is that all set up?

The PR volume on external crates is generally low enough that homu isn't necessary most of the time (unlike for the rust-lang/rust repo)

[gsingh93]

Will there be specific members of the Rust team (or possibly other community members) designated as the main owners/maintainers of the nursery crates? I've tried to open issues/contribute to some of the rust-lang crates before and many of my issues were never responded too, and my pull requests required multiple pings to keep things moving. I also didn't know which Rust team member to ping, as many weren't involved with the crate at all, I had to check the commit history to see who committed most frequently. Giving each nursery crate a designated maintainer might help with this.

[steveklabnik]

Giving each nursery crate a designated maintainer might help with this.

Big 👍 here.

[nikomatsakis]

@aturon

I see; so you were thinking of advertising in all channels, but in a separate "nursery" section? That seems plausible.

Yes, I was.

[mdinger]

s/cratess/crates/

[nrc]

Could we have joint ownership of promoted libs? It seems to really suck that you curate a library for some time, manage it, raise it like a child and then have to give up on it entirely. Could we keep the maintainer as an owner of the repo within rust-lang and have the lib managed by the maintainer and libs team together? Worst case scenario if consensus can't be reached the lib is booted to -deprecated (and either a new version proposed or it gets forked)

[nrc]

I guess there should be some licensing requirement for entering the nursery? I presume the licenses must at least be compatible with the rest of the blessed crates.

[nikomatsakis]

@nrc

Could we have joint ownership of promoted libs? It seems to really suck that you curate a library for some time, manage it, raise it like a child and then have to give up on it entirely.

I'm not 100% sure what joint ownership means. Can you elaborate a bit?

I imagine though that when a lib is promoted, the previous owner would still likely be the primary maintainer, and given due deference on style decisions etc.

[aturon]

@gsingh93

Will there be specific members of the Rust team (or possibly other community members) designated as the main owners/maintainers of the nursery crates?

That's a good question! The Highfive script we use to assign reviewers for PRs can, in principle, be given a separate list of reviewers for each rust-lang crate; these reviewers can also be published somewhere. I think it's fair to say that a crate shouldn't enter the nursery without at least a couple of willing maintainers in the libs team or wider community.

@nrc

Could we have joint ownership of promoted libs? It seems to really suck that you curate a library for some time, manage it, raise it like a child and then have to give up on it entirely.

A couple things. First, I don't think this process requires "giving up on it entirely"; as @nikomatsakis says, the original maintainers would certainly continue to have r+ right and a large amount of deference from the libs team. The RFC could try to formalize this a bit more.

Of course, it's a balance, since an important aspect of the proposal here is community-wide ownership of the crates. One alternative I floated to the libs team was the idea that when a crate enters full rust-lang, its original maintainers are made part of the libs team. To scale that, though, the libs team would have to be itself divided into subteams, and we feel like we already do a reasonable job of looping in people who've made important libs contributions but aren't officially on the team.

[alexcrichton]

This RFC is now entering its week-long final comment period

[bstrie]

I would like to second nrc's licensing question. IMO, for the sake of our sanity, all crates under rust-lang must have the same licensing terms.

Other than that, +1. This is a very important step towards ecosystem maturity.

[rkjnsn]

What happens when a crate like time does get a complete overhaul? Will the crate get moved from “deprecated” back to “nursery” with the new version as 0.2.0? Or will the name be unavailable for future implementations?

[alexcrichton]

The libs team discussed this at the triage meeting this week and the conclusion was to merge this, so I will do so!

---

@rkjnsn I believe that's roughly what we're intending, yeah. The names won't be taken for forever and they may migrate around over time.

[aturon]

Follow-up: we specifically discussed the licensing issue and plan to require all libraries entering the nursery to be licensed identically to Rust itself.