Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://forge.rust-lang.org/compiler/proposals-and-stabilization.html below:

Proposals, Approval and Stabilization - Rust Forge

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

It is very common to need to gather feedback and approval when contributing to the compiler, either for permission to proceed with an experiment or refactoring, or when stabilizing a feature. This document aims to summarise the various processes that the compiler team has for making approval decisions and when each should be used.

There are three mechanisms that the team can use to approve a proposal (not all approval mechanisms are suitable for each method of making a proposal - see below):

• r+
  • A proposal is r+’d when it is approved to be merged.
  • r+ can only be used to approve a PR.
• Seconding
  • A proposal is second’ed when a team member formally endorses the proposal. It is intended that seconding only occur once discussion has concluded and team members have had time to raise concerns. Seconding tentatively accepts a proposal subject to a ten-day waiting period for other team members to raise any concerns.
  • Seconding can only be used to approve a MCP.
• FCP
  • A Final Comment Period is started by a T-compiler member. it’s a tool to get concrete consensus from the team. This requires sign-off from the compiler FCP reviewers (the compiler-fcp subteam) to approve a proposal and then a ten day waiting period.
  • FCPs can be used to approve any form of proposal.

There are three ways to propose a change to the compiler team. The appropriate choice depends on the nature of the proposal, described below.

• Request For Comments (RFC)
  • RFCs are pull requests to the rust-lang/rfcs repository and are a heavy-weight proposal mechanism, reserved for significant changes.
  • RFC proposals can only be approved by FCPs.
• Major Change Proposal (MCP)
  • MCPs are issues in the rust-lang/compiler-team repository and are a medium-weight proposal mechanism, suitable for most proposals. MCPs are recommended for written proposals that are not end-user facing.
  • Introduced in RFC 2904.
  • MCP proposals can be approved by FCPs or Seconding.
• Pull Request (PR)
  • PRs are pull requests to the rust-lang/rust repository and are a light-weight proposal mechanism, suitable for most proposals. PRs are preferred when the proposal is accompanied by a small patchset (such as stabilization of a compiler flag or addition of a new target).
  • PR proposals can be approved by FCPs or r+.

• Open a tracking issue on the rust-lang/compiler-team repo using the major change template.
  • A Zulip topic in the stream #t-compiler/major changes will automatically be created for you by a bot.
  • If concerns are raised, you may want to modify the proposal to address those concerns.
  • Alternatively, you can submit a design meeting proposal to have a longer, focused discussion.
• To be accepted, a major change proposal needs three things:
  • A second, a member of the compiler team who approves of the idea, but is not the one originating the proposal.
  • A final comment period (a 10 day wait to give people time to comment).
    • The FCP can be skipped if the change is easily reversed and/or further objections are considered unlikely. This often happens if there has been a lot of prior discussion, for example.
    • Outstanding concerns block the final comment period from completing.
    • When all outstanding concerns are resolved, the final comment period countdown is restarted.
• Once the FCP completes, if there are no outstanding concerns, contributions can begin.
  • An earlier accepted MCP is not a substitute for any later necessary approvals.

Please direct technical conversation to the Zulip stream.

The compiler-team repo issues are intended to be low traffic and used for procedural purposes.

It is recommended that any team member who wishes to “second” a proposal be familiar with the relevant code. Anyone can note concerns that shouldn’t be overlooked.

These types of procedural comments can be left on the issue (it’s also good to leave a message in Zulip). See the previous section. To facilitate a machine parsable scanning of the concerns please use the following syntax to formally register a concern:

@rustbot concern reason-for-concern

<long description of the concern>

And the following syntax to lift a concern when resolved:

@rustbot resolve reason-for-concern

MCPs can be seconded using:

@rustbot second

Usually the experts in the given area will reach a consensus here, but if there is some need for a “tie breaker” vote or judgment call, the compiler team leads make the final call.

MCPs can be closed:

• by the author, if they have lost interest in pursuing it.
• by a team lead or expert, if there are strong objections from key members of the team that don’t look likely to be overcome.
• by folks doing triage, if there have been three months of inactivity. In this case, people should feel free to re-open the issue if they would like to “rejuvenate” it.

If the approval required for the contribution requires an MCP or an RFC, then the contribution should be closed or marked as blocked, with a request to create an MCP or RFC first. If approval of a PR is acceptable for the specific contribution (see below), then the approval process can begin.

Of course! You are free to work on PRs or write code. But those PRs should be marked as experimental and they should not land, nor should anyone be expected to review them (unless folks want to).

A good proposal will address the following:

• Motivation: Why is this proposal necessary? What problem does it solve? Why is that problem important?
• Design: What are you proposing?
• Implementation notes: You don’t have to talk about the implementation normally, but if there are any key things to note (i.e., it was very invasive to implement), you might note them here.
• Precedent, links, and related material: Have there been similar proposals on other compilers/linkers/tools, like clang or lld?
• Alternatives, concerns, and key decisions: Were there any alernatives considered? If so, why did you pick this design?

This section aims to exhaustively detail which proposal and approval is necessary for any given circumstance.

• Creating a notification group
  • Propose using: PR
  • Approve using: r+
  • If a team member finds the new group reasonable then they can merge the change adding the group.
• Significant internal refactorings/changes
  • Propose using: MCP
  • Approve using: Seconding
  • Describe your proposed refactorings in detail in an MCP - optionally scheduling a steering meeting if more focused discussion is necessary. Once discussion has concluded, a team member may second the proposal
• Defining/changing small team policies
  • Propose using: MCP
  • Approve using: Seconding
  • Examples of smaller policy changes where an MCP would be sufficient include our level of support for case-insensitive filesystems or whether the team intend tracking issues to host discussion
• Defining/changing large team policies
  • Propose using: RFC
  • Approve using: FCP
  • Larger policy changes requiring an FCP include proposals to the team’s structure and membership criteria, etc

• Adding a compiler option for internal-use only (e.g. -Ztreat-bug-as-err)
  • Propose using: PR
  • Approve using: r+
  • If a team member finds the new option reasonable then they can merge the change adding the option
• Adding a simple compiler option with intent to later stabilize
  • Propose using: MCP
  • Approve using: Seconding
  • Simple options, such as exposing an uncontroversial option from LLVM, can be implemented and merged with a seconded MCP and r+ approval from a reviewer. It will need a full FCP when it is later stabilized
• Adding a complex compiler option with intent to later stabilize
  • Propose using: RFC
  • Approve using: FCP
  • If the option is complicated and requires design considerations, then write and submit a t-compiler RFC
• Removing internal-use only flags
  • Propose using: MCP
  • Approve using: Seconding
  • Describe the rationale for removing the unstable implementation. Once discussion has concluded, a team member may second the proposal
• Removing flags which were intended for eventual stabilization
  • Propose using: MCP
  • Approve using: Seconding
  • Describe the rationale for removing the unstable implementation. Once discussion has concluded, a team member may second the proposal
• Stabilizing a compiler option
  • Propose using: PR
  • Approve using: FCP
  • Open a PR and follow the stabilization guide. The assigned reviewer will check that the stabilization guide has been followed, review the code and start an FCP
• Reverting stabilization of a compiler option
  • Propose using: PR
  • Approve using: FCP
  • Open a PR and follow the stabilization guide. The assigned reviewer will check that the stabilization guide has been followed, review the code and start an FCP
• Extending the behavior of a stable flag
  • Propose using: MCP
  • Approve using: Seconding
  • Describe the rationale for extending the behavior of the flag. Once discussion has concluded, a team member may second the proposal

• Adding a attribute for internal-use only (e.g. rustc_attrs)
  • Propose using: PR
  • Approve using: r+
  • If a team member finds the new attribute reasonable then they can merge the change adding the attribute
• Adding a attribute with intent to later stabilize
  • Follow the language team’s process and have the implementation PR reviewed by a member of the compiler team
• Removing internal-use only attributes
  • Propose using: MCP
  • Approve using: Seconding
  • Describe the rationale for removing the unstable implementation. Once discussion has concluded, a team member may second the proposal
• Removing attribute which were intended for eventual stabilization
  • Follow the language team’s process and have the removal PR reviewed by a member of the compiler team
• Stabilizing an attribute
  • Follow the language team’s process and have the stabiization PR reviewed by a member of the compiler team
• Reverting stabilization of an attribute
  • Follow the language team’s process and have the revert PR reviewed by a member of the compiler team

• Adding experimental implementations of not-yet-proposed language features
  • Propose using: MCP
  • Approve using: Seconding
  • With the approval of the language team (that they think the feature is worth experimentation), then submit an RFC and if, after discussion has concluded, a compiler team member agrees that the implementation is feasible and will not put undue burden on the maintainers of the compiler, then they can second the MCP and implementation can proceed.
  • This isn’t necessary if the owner of the implementation is a member of the compiler team
• Stabilizing a language feature
  • Follow the language team’s process and have the stabiization PR reviewed by a member of the compiler team
• Reverting stabilization of a language feature
  • Follow the language team’s process and have the revert PR reviewed by a member of the compiler team

See the Target Tier Policy for detailed requirements for different Target Tiers.

Quick overview for target promotions:

• Proposing a new target
  • Propose using: PR
  • Approve using: r+ (compiler leads)
  • You can r? compiler_leads on the PR to roll one of the compiler leads as the reviewer.
  • Open a PR with the new target (w/ relevant documentation updates) and document adherence to the target tier policy in the description.
  • New targets must start as Tier 3.
  • New targets should be assigned to the compiler team co-leads to check for any licensing concerns and to ensure that any demands on the project infrastructure are considered and checked with relevant teams.
• Promoting a target from Tier 3 to Tier 2
  • Propose using: MCP
  • Approve using: FCP
  • Open a MCP with the target and document adherence to the Tier 2 target policy in the description.
• Promoting a target from Tier 2 to Tier 1
  • Propose using: RFC
  • Approve using: FCP
  • Open a RFC with the target and document adherence to the Tier 1 target policy in the RFC text.

Quick overview for target demotions and removals:

• Demoting a target from Tier 1 to Tier 2, or removing a Tier 1 target
  • Propose using: RFC
  • Approve using: FCP
  • Open a RFC with the target and rationale.
  • Example: RFC: Demote i686-pc-windows-gnu to Tier 2 #3771
• Demoting a target from Tier 2 to Tier 3, or removing a Tier 2 target
  • Propose using: MCP
  • Approve using: FCP
  • Open a MCP with the target and rationale.
• Removing a Tier 3 target
  • Propose using: PR
  • Approve using: r+ (compiler leads)
  • Open a PR with the target and rationale for removing the Tier 3 target.

• Renaming a target or making a breaking change to a tier 3 target
  • Propose using: PR
  • Approve using: r+
  • Open an PR with the proposed rename and describe the motivation for the change and obtain a r+ from the reviewer.
• Renaming a target or making a breaking change to a tier 2 target
  • Propose using: MCP
  • Approve using: FCP
  • Open an MCP describing the motivation for the change and start an FCP to approve, start an FCP.
  • If approved, the change should be accompanied by a blog post announcing the change with a notice period of at least one release before the change applies.
• Renaming a target or making a breaking change to a tier 1 target
  • Propose using: RFC
  • Approve using: FCP
  • Open an RFC describing the motivation for the change and start an FCP to approve, start an FCP.
  • If approved, the change should be accompanied by a blog post announcing the change with a notice period of at least one release before the change applies.
• Changing target baseline (e.g. minimum Darwin or Windows version bump)
  • Propose using: MCP
  • Approve using: FCP
  • Write an MCP describing why the target should have a change of baseline and once discussion has concluded, an FCP can be started to approve the change of baseline.
• Adding/removing target maintainers
  • Propose using: PR
  • Approve using: r+
  • Open a PR with the changes to the target documentation and obtain an r+ from the reviewer.
• Adding a target feature
  • Propose using: PR
  • Approve using: r+
  • Open a PR adding the target feature and obtain an r+ from the reviewer.
• Stabilizing a target feature
  • Propose using: PR
  • Approve using: FCP
  • Open a PR stabilizing the target feature and once the reviewer is happy with the changes, an FCP can be started

• Adding a new warning/error
  • Propose using: PR
  • Approve using: r+
  • Open a PR with the implementation and obtain an r+ from the reviewer
• Adding a new lint group
  • Follow the language team’s process and have the implementation PR reviewed by a member of the compiler team
• Adding a new lint related to compiler features
  • Propose using: MCP
  • Approve using: FCP
  • A lint concerning a detail that is otherwise the responsibility of the compiler team (such as compiler flags) is the responsibility of the compiler to approve, rather than the language team.
  • Write an MCP describing the lint and its justification and once discussion has concluded, an FCP can be started to approve the new lint
• Adding a new future compatibility warning (FCW) related to compiler features
  • Propose using: MCP
  • Approve using: FCP
  • A FCW concerning a detail that is otherwise the responsibility of the compiler team (such as compiler flags) is the responsibility of the compiler to approve, rather than the language team.
  • Write an MCP describing the FCW and its justification and once discussion has concluded, an FCP can be started to approve the new FCW
• Changing default lint level of a lint related to compiler features
  • Propose using: MCP
  • Approve using: FCP
  • A lint concerning a detail that is otherwise the responsibility of the compiler team (such as compiler flags) is the responsibility of the compiler to approve, rather than the language team.
  • Write an MCP describing the rationale for changing the default lint level and once discussion has concluded, an FCP can be started to approve the new lint
• Adding a new lint related to language features
  • Follow the language team’s process and have the implementation PR reviewed by a member of the compiler team
• Adding a new future compatibility warning (FCW) related to language features
  • Follow the language team’s process and have the implementation PR reviewed by a member of the compiler team
• Changing default lint level of a lint related to language features
  • Follow the language team’s process and have the implementation PR reviewed by a member of the compiler team

• Introducing a new dependency/license change/dependency bump
  • Propose using: PR
  • Approve using: r+ (compiler leads)
  • Open a PR with the change affecting licensing and assign it to the team leads for review

See Backports.

See Adding ecosystem/integration test jobs/components to rust-lang/rust CI.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4