iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[pep-8002] Include clarifications from @alexcrichtonx

This commit is contained in:
Łukasz Langa 2018-08-29 08:04:48 -07:00
parent 87d93b0b60
commit 660be17127
1 changed files with 34 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
pep-8002.rst
View File

@ -26,8 +26,9 @@ Rust
The governance structure is documented in `Rust RFC #1068 The governance structure is documented in `Rust RFC #1068
<https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md>`_. <https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md>`_.
The effective governance process grew organically over time without being entirely The effective governance process grows organically over time without being entirely
codified. One example is the `formation of Domain Working Groups codified as RFCs, especially in case of day-to-day operation details. One example is
the `formation of Domain Working Groups
<https://internals.rust-lang.org/t/announcing-the-2018-domain-working-groups/6737>`_ in <https://internals.rust-lang.org/t/announcing-the-2018-domain-working-groups/6737>`_ in
February 2018. February 2018.
@ -42,7 +43,7 @@ makers. Typically the faciliators are authors of the proposed changes (see
involved along with interested community members. They push towards an agreeable involved along with interested community members. They push towards an agreeable
outcome via iteration. outcome via iteration.
In practice this means the core team is rarely key in a decision. In practice this means decisions are rarely escalated to the core team.
The most common role of a contributor is team membership. Issue triage/code review The most common role of a contributor is team membership. Issue triage/code review
privileges without team membership is rare. Contributors have full commit access, privileges without team membership is rare. Contributors have full commit access,
@ -56,14 +57,16 @@ Regular decision process
------------------------ ------------------------
Primary work happens via GitHub issues and pull requests. Approving a pull request Primary work happens via GitHub issues and pull requests. Approving a pull request
by any team member allows it to be merged without further process. by any team member allows it to be merged without further process. All merged pull
requests end up in the next stable version of Rust.
Notifying relevant people by mentions is important. Listening to the firehose of Notifying relevant people by mentions is important. Listening to the firehose of
e-mails for all GitHub activity is not popular. e-mails for all GitHub activity is not popular.
There are planning and triage meetings open to the public happening on IRC and Discord. There are planning and triage meetings open to the public happening on IRC and Discord.
They are not very popular because most of work happens through GitHub. Discussions also They are not very popular because most of work happens through GitHub. Discussions also
happen in the *r/rust* subreddit. There is a dedicated moderation team responsible for happen on official Rust forums (https://users.rust-lang.org/ and
https://internals.rust-lang.org/). There is a dedicated moderation team responsible for
taking notes and enforcing `code of conduct taking notes and enforcing `code of conduct
<https://www.rust-lang.org/en-US/conduct.html>`_. <https://www.rust-lang.org/en-US/conduct.html>`_.
@ -72,10 +75,12 @@ Controversial decision process
Larger or controversial work goes through a `RFC process Larger or controversial work goes through a `RFC process
<https://github.com/rust-lang/rfcs>`_. It allows everyone to express their thoughts and <https://github.com/rust-lang/rfcs>`_. It allows everyone to express their thoughts and
iterates towards a resolution. At some point when all concerns of relevant team iterates towards a resolution. At some point when all blocking concerns of relevant
members are addressed, they sign off on the RFC and it reaches a "final comment period". team members are addressed, they sign off on the RFC and it reaches a "final comment
period". That does not require consensus amongst all participants, rather there should
not be a strong consensus against the proposal.
After 7-10 days the RFC is *merged* unless any "blocking concerns" are raised by team After 10 days the RFC is *merged* unless any new blocking concerns are raised by team
members. A "merge" signifies that work towards implementing the feature and integrating members. A "merge" signifies that work towards implementing the feature and integrating
it can now happen without interruption. An RFC doesn't have to have a reference it can now happen without interruption. An RFC doesn't have to have a reference
implementation for it to be accepted. implementation for it to be accepted.
@ -83,13 +88,12 @@ implementation for it to be accepted.
The other possible results of the "final comment period" are to: The other possible results of the "final comment period" are to:
* *postpone* the RFC (similar to the Deferred status in PEPs), * *postpone* the RFC (similar to the Deferred status in PEPs),
* get it *back into discussion* if "blocking concerns" can be addressed, or * get it *back into discussion* if blocking concerns can be addressed, or
* *close it* if "blocking concerns" are not solvable. When an RFC is marked as * *close it* if blocking concerns are not solvable. When an RFC is marked as
*closed*, there is a 7 day grace period to debate whether it should be closed. *closed*, there is a 7 day grace period to debate whether it should be closed.
In practice registering concerns with an RFC happens very often initially but rarely In practice registering concerns with an RFC happens very often initially but rarely
causes for the RFC to be entirely killed. There were no cases of an RFC reaching the causes for the RFC to be entirely killed.
"final comment period" but not actually being eventually merged.
This process scales well for small-contention changes and/or smaller changes. For the This process scales well for small-contention changes and/or smaller changes. For the
largest controversial changes the discussion gets unwieldy. This is a topic currently largest controversial changes the discussion gets unwieldy. This is a topic currently
@ -107,11 +111,28 @@ Every six weeks the Rust compiler is released with whatever it contained at the
There are no LTS channels or releases yet but this concept is planned to make There are no LTS channels or releases yet but this concept is planned to make
redistributors able to keep up with development better. redistributors able to keep up with development better.
Every year there is going to be an "Edition" release. Those are milestone releases. Every few years a so-called `"Edition"
<https://rust-lang-nursery.github.io/edition-guide/editions/index.html>`_ is released.
Those are milestone releases with full sets of updated documentation and tooling. They
can be backwards incompatible with previous editions. External packages opt into
breaking changes in their crate metadata. The Rust compiler supports all editions that
existed prior to its release. Linking between crates of any supported edition is
possible.
Changes in the process over time Changes in the process over time
-------------------------------- --------------------------------
The Rust programming language was started by Graydon Hoare who developed it as
a personal project for a few years. When Mozilla started sponsoring the project,
the team slowly grew with Graydon as a BDFL-style figure. He `left the project
<https://www.reddit.com/r/rust/comments/7qels2/i_wonder_why_graydon_hoare_the_author_of_rust/dsqeh1d/>`_
in 2013. Rust functions without a BDFL since. The RFC process was put in place later.
Initially some design discussions happened during closed-door weekly video meetings
which was `shut down
<https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2015-05-26.md#future-of-weekly-meeting>`_
in May 2015 (before the 1.0 release of Rust), organically replaced with open discussion
and direct influence of teams.
The number of teams is growing in time. The number of technical decisions made by the The number of teams is growing in time. The number of technical decisions made by the
core team is decreasing, instead those get delegated to respective teams. core team is decreasing, instead those get delegated to respective teams.