Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upRFC: The Life and Death of an API #1213
Conversation
Gankro
added
the
T-libs
label
Jul 17, 2015
Gankro
self-assigned this
Jul 17, 2015
This comment has been minimized.
This comment has been minimized.
|
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. |
This comment has been minimized.
This comment has been minimized.
|
|
This comment has been minimized.
This comment has been minimized.
|
Seems ok to me. I agree with @nrc this should be in the README though. |
This comment has been minimized.
This comment has been minimized.
|
That's cool with me; I misunderstood what nrc was asking for. Although On Fri, Jul 17, 2015 at 1:47 PM, Brian Anderson notifications@github.com
|
ruuda
reviewed
Jul 21, 2015
| 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.
This comment has been minimized.
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.
This comment has been minimized.
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
ruuda
reviewed
Jul 21, 2015
|
|
||
| # Drawbacks | ||
|
|
||
| Less gutfeels, moar process? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
alexcrichton
referenced this pull request
Jul 21, 2015
Merged
RFC: Stabilize the #![no_std] attribute #1184
This comment has been minimized.
This comment has been minimized.
|
In #1184 Gankro says:
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. |
This comment has been minimized.
This comment has been minimized.
|
@Ericson2314 that seems reasonable to me, yes. |
nrc
added a commit
to nrc/rfcs
that referenced
this pull request
Jul 27, 2015
nrc
referenced this pull request
Jul 27, 2015
Merged
Update the RFC process with sub-teams, amongst other things. #1224
This comment has been minimized.
This comment has been minimized.
|
Killing in favour of #1224 |
Gankro commentedJul 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