Sync Fork from Upstream Repo #22
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Rust developers regularly implement new targets in the Rust compiler, and reviewers of pull requests for such new targets would like a clear, consistent policy to cite for accepting or rejecting such targets. Currently, individual reviewers do not know what overall policy to apply, and whether to apply solely their own judgment or defer to a Rust governance team. Rust developers regularly ask how they can raise an existing target to tier 2 (and in particular how they can make it available via rustup), and occasionally ask what it would take to add a new tier 1 target. The Rust project has no clear official policy for target tiers. People not only don't know, they don't know who to ask or where to start. This proposal documents an official policy for adding new (tier 3) targets, and for raising targets to tier 2 (with rustup builds) or to tier 1. Based on discussions with the compiler team and representatives from other teams.
Thanks to pietroalbini for suggesting "marker teams" in rust-lang/team, and for elaborating on downsides of using GitHub team membership.
Also explain a common case where this may come up.
… etc Also discuss the approval requirements for changes to those expectations, such as dropping or demoting support for older OSes or CPUs based on changes in usage within the Rust community.
"nominal" is intentionally subjective.
…own binaries No existing tier 1 target has a hard requirement for this, so we don't need an exception for existing targets.
Enhancing other documentation of the target is welcome and encouraged.
… release" For instance, we might demote or remove a target more quickly and with less notice if it has never been part of a stable release.
Make this requirement conditional on the target having an interoperable calling convention for C code.
This exception applies only when introducing a tier 2 target to cover baseline expectations beneath those of an existing tier 1 target (e.g. supporting older OSes or CPUs). Suggested by Felix Klock.
Make it even more clear that this requirement only applies to tier 3, not to higher tiers (which otherwise inherit lower-tier requirements).
Tier 2 and tier 1 targets place work on Rust project developers, specifically; describe it as such rather than "the Rust community". Also add the observation that the broader community may feel more inclination to support higher-tier targets, but clarify that people are not obligated to do so.
Also qualify that as "existing target"; an existing target could use issues to track progress towards tier 2 or tier 1, but an aspiring tier 3 target using issues on the Rust repo may or may not be appropriate.
Just reference the tidy tool itself.
This isn't a feature that will go through a stabilization cycle, so it doesn't need a tracking issue.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.