On 03/12/2014 12:54 AM, Flaper87 wrote:
2014-03-12 2:11 GMT+01:00 Brian Anderson <bander...@mozilla.com
<mailto:bander...@mozilla.com>>:
[snip]
-----
Many changes, including bug fixes and documentation improvements can
be implemented and reviewed via the normal GitHub pull request workflow.
Some changes though are "substantial", and we ask that these be put
through a bit of a design process and produce a consensus among the
Rust community and the [core team].
The "RFC" (request for comments process) is intended to provide a
consistent and controlled path for new features to enter the
language and standard libraries, so that all stakeholders can be
confident about the direction the language is evolving in.
## When you need to follow this process
You need to follow this process if you intend to make "substantial"
changes to the Rust distribution. What constitutes a "substantial"
change is evolving based on community norms, but may include the
following.
- Any semantic or syntactic change to the language that is not a
bugfix.
- Changes to the interface between the compiler and libraries,
including lang items and intrinsics.
- Additions to `std`
Some changes do not require an RFC:
- Rephrasing, reorganizing, refactoring, or otherwise "changing
shape does not change meaning".
- Additions that strictly improve objective, numerical quality
criteria (warning removal, speedup, better platform coverage, more
parallelism, trap more errors, etc.)
- Additions only likely to be _noticed by_ other
developers-of-rust, invisible to users-of-rust.
If you submit a pull request to implement a new feature without
going through the RFC process, it may be closed with a polite
request to submit an RFC first.
## What the process is
In short, to get a major feature added to Rust, one must first get
the RFC merged into the RFC repo as a markdown file. At that point
the RFC is 'active' and may be implemented with the goal of eventual
inclusion into Rust.
* Fork the RFC repo http://github.com/rust-lang/__rfcs
<http://github.com/rust-lang/rfcs>
* Copy `0000-template.md <http://0000-template.md>` to
`active/0000-my-feature.md <http://0000-my-feature.md>` (where
'my-feature' is descriptive. don't assign an RFC number yet).
What about using the PR's number? That means we'll end up with some gaps
between accepted RFCs but... just thinking aloud.
We've discussed this but decided against, though the argument doesn't
seem to be that strong either way.
* Fill in the RFC
* Submit a pull request. The pull request is the time to get review
of the design from the larger community.
* Build consensus and integrate feedback. RFCs that have broad
support are much more likely to make progress than those that don't
receive any comments.
* Eventually, somebody on the [core team] will either accept the RFC
by merging the pull request and assigning the RFC a number, at which
point the RFC is 'active', or reject it by closing the pull request.
We should also use tags: `Rejected` / `Approved`
I'm specifically trying to avoid those words :) 'approved' is stronger
than I want, because an approved RFC still may not get merged into the
language, and being 'rejected' is unfun.
I'm wondering if we should keep rejected RFCs too and not just as closed
PRs. If for some reason, this repo is moved out of GH in the future,
we'd loose a bunch of RFC history. We could keep the first rejected RFC
for a type of change and reject future duplicated RFCs by linking them
to that RFC. Not sure about this, though.
I do think this is a good idea, particularly for good RFCs that we
nonetheless don't want to implement. I haven't put any language in about
doing this but I suspect it will happen anyway when the proper case arises.
Once an RFC becomes active then authors may implement it and submit
the feature as a pull request to the Rust repo. An 'active' is not a
rubber stamp, and in particular still does not mean the feature will
ultimately be merged; it does mean that in principle all the major
stakeholders have agreed to the feature and are amenable to merging it.
Modifications to active RFC's can be done in followup PR's. An RFC
that makes it through the entire process to implementation is
considered 'complete' and is moved to the 'complete' folder; an RFC
that fails after becoming active is 'inactive' and moves to the
'inactive' folder.
We also need a way to track who's working on that RFC. Should an RFC bug
be created in Rust's repo and be linked to the real RFC ? This way folks
can raise their hands and work on the RFC, it's also a good place for
follow-up discussions on the work happening for that RFC, etc. The
person proposing the RFC is not necessarily the one that will work on it.
I've added language to the current RFC PR[1] about opening Rust issues
for active RFCs.
[1]: https://github.com/rust-lang/rfcs/pull/6
I was going to suggest having a way to automatically close and move the
active RFC under the complete folder but I think this process requires
some double checking from the [core team] so I'd prefer keeping it that way.
### Help this is all too informal!
The process is intended to be as lightweight as reasonable for the
present circumstances. As usual, we are trying to let the process be
driven by consensus and community norms, not impose more structure
than necessary.
FWIW, I've seen a similar process being implemented in other projects.
Using the review infrastructure to propose RFCs sounds like a good idea
to me. The only bit that worries me is having a good way to search
through the RFCs history (like real search, not just `git grep` or GH's
search field), hence the proposal of keeping some of the rejected RFCs.
We could have a `rfc.rust-lang.org <http://rfc.rust-lang.org>` with the
RFCs indexed and allow people to navigate active, rejected and completed
RFCs from there.
Possible, yes. I hope we have enough RFCs someday that keeping them
organized becomes a problem.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
