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

RFC: policy for rust-lang crates #1242

Merged
merged 4 commits into from Aug 27, 2015

Conversation

Projects
None yet
@aturon
Member

aturon commented Aug 7, 2015

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

@aturon aturon added the T-libs label Aug 7, 2015

@aturon aturon self-assigned this Aug 7, 2015

Please volunteer if you're interested in taking one of these on!
- rlibc
- semver

This comment has been minimized.

@steveklabnik

steveklabnik Aug 7, 2015

Member

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

@steveklabnik

steveklabnik Aug 7, 2015

Member

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

This comment has been minimized.

@brson

brson Aug 7, 2015

Contributor

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.

@brson

brson Aug 7, 2015

Contributor

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.

This comment has been minimized.

@steveklabnik

steveklabnik Aug 7, 2015

Member

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

@steveklabnik

steveklabnik Aug 7, 2015

Member

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

- regex
- rustc-serialize (but will likely be replaced by serde or other approach eventually)
- tempdir (destined for `std` after reworking)
- uuid

This comment has been minimized.

@sfackler

sfackler Aug 7, 2015

Member

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

@sfackler

sfackler Aug 7, 2015

Member

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

This comment has been minimized.

@aturon

aturon Aug 7, 2015

Member

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

@aturon

aturon Aug 7, 2015

Member

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

libs subteam can deprecate nursery crates at any time, and can deprecate
rust-lang crates through an RFC. This is expected to be a rare occurrence.
Deprecated crates move to rust-lang-deprecated and are subsequently minimally

This comment has been minimized.

@sfackler

sfackler Aug 7, 2015

Member

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

sfackler Aug 7, 2015

Member

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.

- tempdir (destined for `std` after reworking)
- uuid
### Move to rust-lang-deprecated

This comment has been minimized.

@sfackler

sfackler Aug 7, 2015

Member

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.

@sfackler

sfackler Aug 7, 2015

Member

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.

This comment has been minimized.

@steveklabnik

steveklabnik Aug 7, 2015

Member

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.

@steveklabnik

steveklabnik Aug 7, 2015

Member

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

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Aug 7, 2015

Contributor

@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.

Contributor

nikomatsakis commented Aug 7, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Aug 7, 2015

Member

@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.

Member

aturon commented Aug 7, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Aug 7, 2015

Contributor

@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.)

Contributor

nikomatsakis commented Aug 7, 2015

@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.)

- hexfloat: niche
- num: this is essentially a dumping ground from 1.0 stabilization; needs a complete re-think.
- term: API needs total overhaul
- time: needs total overhaul destined for std

This comment has been minimized.

@brson

brson Aug 7, 2015

Contributor

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

@brson

brson Aug 7, 2015

Contributor

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

This comment has been minimized.

@alexcrichton

alexcrichton Aug 10, 2015

Member

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

@alexcrichton

alexcrichton Aug 10, 2015

Member

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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Aug 7, 2015

Contributor

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?

Contributor

brson commented Aug 7, 2015

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

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Aug 7, 2015

Member

@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.

Member

aturon commented Aug 7, 2015

@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.

# Unresolved questions
Part of the maintenance standard for Rust is the CI infrastructure, including
bors/homu. What level of CI should we provide for these crates, and how do we do it?

This comment has been minimized.

@SimonSapin

SimonSapin Aug 7, 2015

Contributor

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/

@SimonSapin

SimonSapin Aug 7, 2015

Contributor

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/

This comment has been minimized.

@Gankro

Gankro Aug 7, 2015

Contributor

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.

@Gankro

Gankro Aug 7, 2015

Contributor

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.

This comment has been minimized.

@alexcrichton

alexcrichton Aug 10, 2015

Member

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)

@alexcrichton

alexcrichton Aug 10, 2015

Member

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

This comment has been minimized.

Show comment
Hide comment
@gsingh93

gsingh93 Aug 7, 2015

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.

gsingh93 commented Aug 7, 2015

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

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Aug 7, 2015

Member

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

Big 👍 here.

Member

steveklabnik commented Aug 7, 2015

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

Big 👍 here.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Aug 7, 2015

Contributor

@aturon

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

Yes, I was.

Contributor

nikomatsakis commented Aug 7, 2015

@aturon

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

Yes, I was.

- rust-lang-nursery
- rust-lang-deprecated
New cratess start their life in a `0.X` series that lives in the

This comment has been minimized.

@mdinger

mdinger Aug 8, 2015

Contributor

s/cratess/crates/

@mdinger

mdinger Aug 8, 2015

Contributor

s/cratess/crates/

library subteam may be a disincentive for library authors, since they lose
unilateral control of their libraries. But this is an inherent aspect of the
policy design, and the vastly increased visibility of libraries is likely a
strong enough incentive to overcome this downside.

This comment has been minimized.

@nrc

nrc Aug 9, 2015

Member

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

nrc Aug 9, 2015

Member

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

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Aug 9, 2015

Member

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.

Member

nrc commented Aug 9, 2015

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

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Aug 11, 2015

Contributor

@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.

Contributor

nikomatsakis commented Aug 11, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Aug 11, 2015

Member

@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.

Member

aturon commented Aug 11, 2015

@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 comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Aug 20, 2015

Member

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

Member

alexcrichton commented Aug 20, 2015

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

@bstrie

This comment has been minimized.

Show comment
Hide comment
@bstrie

bstrie Aug 25, 2015

Contributor

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.

Contributor

bstrie commented Aug 25, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rkjnsn

rkjnsn Aug 26, 2015

Contributor

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?

Contributor

rkjnsn commented Aug 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Aug 27, 2015

Member

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.

Member

alexcrichton commented Aug 27, 2015

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.

@alexcrichton alexcrichton merged commit a690d2f into rust-lang:master Aug 27, 2015

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Aug 27, 2015

Member

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

Member

aturon commented Aug 27, 2015

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

@chriskrycho chriskrycho referenced this pull request Mar 29, 2017

Closed

Document all features #9

18 of 48 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment