Skip to content
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: The Life and Death of an API #1213

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
6 participants
@Gankro
Copy link
Contributor

Gankro commented Jul 17, 2015

Adds a proper path for APIs to migrate from unstable to stable, including a
full shepherd and final comment period. Also establishes guidelines for
how RFCs and PRs should be handled and when RFCs or PRs should be preferred.

Rendered

@Gankro Gankro added the T-libs label Jul 17, 2015

@Gankro Gankro self-assigned this Jul 17, 2015

@nrc

This comment has been minimized.

Copy link
Member

nrc commented Jul 17, 2015

I intend to edit README.md to include some of the general process stuff and then have per-sub-team specifics linked from there (not as meta-RFCs). I'll use this as the basis for the libs doc. Lets discuss here, but the path forward will probably be closing this PR and taking the text elsewhere.

@alexcrichton

This comment has been minimized.

Copy link
Member

alexcrichton commented Jul 17, 2015

👍

@brson

This comment has been minimized.

Copy link
Contributor

brson commented Jul 17, 2015

Seems ok to me. I agree with @nrc this should be in the README though.

@Gankro

This comment has been minimized.

Copy link
Contributor Author

Gankro commented Jul 17, 2015

That's cool with me; I misunderstood what nrc was asking for. Although
there are still some details to hash out they could probably just as easily
be hashed out on internals. Although perhaps this benefits from being in a
more public forum (internals being more insular)?

On Fri, Jul 17, 2015 at 1:47 PM, Brian Anderson notifications@github.com
wrote:

Seems ok to me. I agree with @nrc https://github.com/nrc this should be
in the README though.


Reply to this email directly or view it on GitHub
#1213 (comment).

professionals are super busy *and* have no responsibility to engage in RFCs. Since
these are *exactly* the most important people to get involved in the RFC process,
it is important that we be maximally friendly towards their needs. We cannot build
a robust language using only the opinion of hobbyists and students with all the time

This comment has been minimized.

@ruuda

ruuda Jul 21, 2015

I think having all the time in the world and being a hobbyist or student are pretty much orthogonal.

This comment has been minimized.

@Gankro

Gankro Jul 21, 2015

Author Contributor

They're pretty highly correlated in my experience. A non-trivial percentage of our most active contributors are:

  • Mozilla employees who are literally paid to work on Rust and Rust Accessories
  • Students who are volunteering their time

# Drawbacks

Less gutfeels, moar process?

This comment has been minimized.

@ruuda

ruuda Jul 21, 2015

Is that typo intentional?

This comment has been minimized.

@Gankro

Gankro Jul 21, 2015

Author Contributor

yes

@Ericson2314

This comment has been minimized.

Copy link
Contributor

Ericson2314 commented Jul 22, 2015

In #1184 Gankro says:

APIs need not be in their final form before being stabilized. They just need to go through an FCP, at the end of which it is reasonable to make a minor tweak (as is the case for RFCs). The beta-period ensures that they will be in their final form for a whole period before hitting stable.

An API should be unstable for >= 1 cycles, then FCP for 1 cycle, then stable for a beta period, and then "stable on stable". On the unstable->FCP, or FCP->stable transitions, it may be amended? But once it is in beta it must be sent back to unstable or kept as is? Sounds fine, just want to (again) clarify.

@Gankro

This comment has been minimized.

Copy link
Contributor Author

Gankro commented Jul 24, 2015

@Ericson2314 that seems reasonable to me, yes.

nrc added a commit to nrc/rfcs that referenced this pull request Jul 27, 2015

Update the RFC process with sub-teams, amongst other things.
The libs section was authored by @Gankro, see rust-lang#1213 and [this discuss thread](https://internals.rust-lang.org/t/the-life-and-death-of-an-api/2087) for previous discussion.

We're currently missing guideline for the tools sub-team. I just didn't have anything to hand, hopefully we can remedy that in a followup PR.
@Gankro

This comment has been minimized.

Copy link
Contributor Author

Gankro commented Aug 10, 2015

Killing in favour of #1224

@Gankro Gankro closed this Aug 10, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.