From 14a9c4fdd86e7ac7a61a256956dd251c39cddde6 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 3 Nov 2019 16:25:47 -0800 Subject: [PATCH 001/166] Target tier policy 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. --- text/0000-target-tier-policy.md | 222 ++++++++++++++++++++++++++++++++ 1 file changed, 222 insertions(+) create mode 100644 text/0000-target-tier-policy.md diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md new file mode 100644 index 00000000000..d468a016773 --- /dev/null +++ b/text/0000-target-tier-policy.md @@ -0,0 +1,222 @@ +- Feature Name: `target_tier_policy` +- Start Date: 2019-09-20 +- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000) +- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000) + +# Summary +[summary]: #summary + +We should have an official, objective policy for adding new (tier 3) targets, +and for raising targets to tier 2 (with rustup builds) or even tier 1. + +# Motivation +[motivation]: #motivation + +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 policy for target tiers. People not only don't know, they don't know who +to ask or where to start. + +(See https://forge.rust-lang.org/platform-support.html for more information +about targets and tiers.) + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +At a high level, the three tiers break down as follows: + +- Tier 3 targets provide no guarantees of support. +- Tier 2 targets will always build, but may not pass tests. +- Tier 1 targets will always build and pass tests. + +Adding a new tier 3 target imposes minimal requirements; we focus primarily on +avoiding disruption to other ongoing Rust development. + +Tier 2 and tier 1 targets place work on the Rust community as a whole, to avoid +breaking the target. Thus, these tiers require commensurate efforts from the +maintainers of the target, to demonstrate value and to minimize any disruptions +to ongoing Rust development. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +Requirements for each tier: + +## Tier 3 target policy + +At this tier, the Rust project provides no official support for a target, so we +place minimal requirements on the introduction of targets. + +- No central decision is required to add a new tier 3 target. Reviewers may + always use their own best judgment regarding the quality of work, and the + suitability of a target for the Rust project. +- If a reviewer wishes to consult a broader team for additional guidance, they + should contact the compiler team. +- If a proposed target or target-specific patch substantially changes code + shared with other targets (not just target-specific code), the reviewer + should consult the compiler team. +- If the proposer of a target wishes to appeal the rejection of a target, they + may contact the compiler team. +- Tier 3 targets must use naming consistent with any existing targets; for + instance, a target for a similar CPU or OS should not gratuitously use an + inconsistent name for that CPU or OS. Targets should normally use the same + names as used elsewhere in the broader ecosystem (such as in other + toolchains), unless they have a very good reason to diverge. +- Tier 3 targets may have unusual requirements to build or use, but must not + create legal issues for the Rust project or for developers who work on those + targets. +- Where possible, tier 3 targets may wish to provide documentation for the Rust + community for how to build and run tests for the platform, ideally using + emulation. +- Tier 3 targets must not impose burden on the authors of pull requests, or + other developers in the community, to maintain the target. In particular, + do not post comments (automated or manual) on a PR that suggests a block on + the PR based on the target. (A PR author may choose to help with a tier 3 + target but is not required to.) +- Patches adding or updating tier 3 targets must not break any existing target. +- If a tier 3 target shows no signs of activity and has not built for some + time, and removing it would improve the quality of the Rust codebase, we may + post a PR to remove it; any such PR will be CCed to people who have + previously worked on the platform, to check potential interest. + +## Tier 2 target policy + +At this tier, the Rust project guarantees that a target builds, and will reject +patches that fail to build on a target. Thus, we place requirements that ensure +the target will not block forward progress of the Rust project. + +- Any new tier 2 target requires compiler team approval based on these + requirements. +- In addition, the infrastructure team must approve the integration of the + target into CI, and the CI-related requirements. This review and approval + will typically take place in the PR adding the target to CI. +- A tier 2 target must have value to people other than its maintainers. +- Any new tier 2 target must have a designated team of developers on call to + consult on target-specific build-breaking issues, or if necessary to develop + target-specific language or library implementation details. (This team should + in almost all cases have at least 2 developers.) +- The target must not place undue burden on Rust developers not specifically + concerned with that target. Rust developers may be expected to not + gratuitously break a tier 2 target, but are not expected to become experts in + every tier 2 target, and are not expected to provide target-specific + implementations for every tier 2 target. +- Where possible, tier 2 targets should provide documentation for the Rust + community for how to build and run tests for the platform, ideally using + emulation. +- The target development team should not only fix target-specific issues, but + should use any such issue as an opportunity to educate the Rust community + about portability to their target, and enhance their documentation of the + target. +- The target must build reliably in CI. +- Building the target must not take substantially longer than other targets. +- Tier 2 targets must support building on the existing targets used for CI + infrastructure. +- Tier 2 targets must not impose burden on the authors of pull requests, or + other developers in the community, to ensure that tests pass for the target. + In particular, do not post comments (automated or manual) on a PR that + suggests a block on the PR based on tests failing for the target. (A PR + author must not break the build of a tier 2 target, but need not ensure the + tests pass for a tier 2 target, even if notified that they fail.) +- The target development team should regularly run the testsuite for the + target, and should fix any test failures in a reasonably timely fashion. +- A tier 2 target may be demoted or removed if it no longer meets these + requirements. Any proposal for demotion or removal will be CCed to people who + have previously worked on the platform, and will be communicated widely to + the Rust community before being dropped from a stable release. +- All tier 3 requirements apply. + +Note: some tier 2 platforms additionally have binaries built to run on them as +a host (such as `rustc` and `cargo`). Such a platform must meet all the +requirements above, and must additionally get the compiler and infrastructure +team to approve the building of host tools. + +## Tier 1 target policy + +At this tier, the Rust project guarantees that a target builds and passes all +tests, and will reject patches that fail to build or pass the testsuite on a +target. We hold tier 1 targets to our highest standard of requirements. + +- Any new tier 1 target requires compiler team approval based on these + requirements. +- In addition, the infrastructure team must approve the integration of the + target into CI, and the CI-related requirements. This review and approval + will typically take place in the PR adding the target to CI. +- In addition, the release team must approve the long-term viability of the + target, and the additional work of supporting the target. +- Tier 1 targets must have substantial, widespread interest within the + developer community, and must serve the ongoing needs of multiple production + users of Rust across multiple organizations or projects. A tier 1 target may + be demoted or removed if it becomes obsolete or no longer meets this + requirement. +- The target must build and pass tests reliably in CI. +- Building the target and running the testsuite for the target must not take + substantially longer than other targets. +- If running the testsuite requires additional infrastructure (such as systems + running the target), the target development team shall arrange to provide + such resources to the Rust project, to the satisfaction and approval of the + Rust infrastructure team. +- Tier 1 targets must provide documentation for the Rust community for how to + build and run tests for the platform, using emulation if possible, or + dedicated hardware if necessary. +- A tier 1 target may be demoted or removed if it no longer meets these + requirements. Any proposal for demotion or removal will be communicated + widely to the Rust community, both when initially proposed and before being + dropped from a stable release. +- All tier 2 requirements apply. + +# Drawbacks +[drawbacks]: #drawbacks + +While these criteria attempt to document the policy, that policy still involves +human judgment. Targets must fulfill the spirit of the requirements as well, as +determined by the judgment of the approving teams. + +# Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +The set of approving teams for each tier arose out of discussion with the +various teams involved with aspects of the Rust project impacted by new +targets. + + +# Prior art +[prior-art]: #prior-art + +This attempts to formalize and document Rust policy around targets and +architectures. https://forge.rust-lang.org/release/platform-support.html +documents some of that policy. + +Future expansions of such policy may find requirements from other communities +useful as examples, such as Debian's [arch +policy](https://release.debian.org/bullseye/arch_policy.html) and [archive +criteria](https://ftp-master.debian.org/archive-criteria.html). + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + +- Where, precisely, should we post the official policy? +- How should we track the maintainers of a target, so that we can page them if + we need an issue addressed involving that target? Can we do so using github + teams, so that we can mention them in an issue or PR to get their attention? + +# Future possibilities +[future-possibilities]: #future-possibilities + +Eventually, as more targets seek tier 1 status, we may want to document more +criteria used to evaluate requirements such as "long-term viability of the +target". We should also update these requirements if corner cases arise. + +Some of our existing ports may not meet all of these criteria today. We may +wish to audit existing ports against these criteria, but this RFC does not +constitute a commitment to do so in a timely fashion. + +This RFC should not serve as the canonical home of the most up-to-date version +of this policy; the official policy should live on rust-lang.org and in +official documentation. From 2eb8f5f4ff4f01344bede48626560bd171890ca9 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Fri, 10 Jul 2020 23:31:16 -0700 Subject: [PATCH 002/166] Document where we should post the official target tier policy --- text/0000-target-tier-policy.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index d468a016773..f2b515cd2d8 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -44,6 +44,9 @@ breaking the target. Thus, these tiers require commensurate efforts from the maintainers of the target, to demonstrate value and to minimize any disruptions to ongoing Rust development. +The policy sections of this RFC should be posted on +https://forge.rust-lang.org/ in a "Target Tier Policy" section. + # Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -201,7 +204,6 @@ criteria](https://ftp-master.debian.org/archive-criteria.html). # Unresolved questions [unresolved-questions]: #unresolved-questions -- Where, precisely, should we post the official policy? - How should we track the maintainers of a target, so that we can page them if we need an issue addressed involving that target? Can we do so using github teams, so that we can mention them in an issue or PR to get their attention? From 58240cf460ec73bc74b2cc1716cc622845996b0d Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 10:44:04 -0700 Subject: [PATCH 003/166] Expand discussion of how to track and reach target maintainers Thanks to pietroalbini for suggesting "marker teams" in rust-lang/team, and for elaborating on downsides of using GitHub team membership. --- text/0000-target-tier-policy.md | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index f2b515cd2d8..186f7e61988 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -205,8 +205,20 @@ criteria](https://ftp-master.debian.org/archive-criteria.html). [unresolved-questions]: #unresolved-questions - How should we track the maintainers of a target, so that we can page them if - we need an issue addressed involving that target? Can we do so using github - teams, so that we can mention them in an issue or PR to get their attention? + we need an issue addressed involving that target? + - We could use github teams, which could be directly mentioned in an issue or + PR to get their attention. However, this would also put a "Member" badge on + the members of those teams, which may give an unwarranted appearance of + official status. + - We could track them in a document posted somewhere, and manually copy-paste + the list to ping them. + - We could add them as a "marker team" (e.g. `target-xyz`) in the + [rust-lang/team](https://github.com/rust-lang/team) repository. For + example, see [the icebreakers-llvm + team](https://github.com/rust-lang/team/blob/master/teams/icebreakers-llvm.toml). + This would allow pinging them with `@rustbot ping target-xyz`. + - We could additionally teach rustbot to automatically ping a target team + when an issue is labeled with a target-specific label. # Future possibilities [future-possibilities]: #future-possibilities From c883f5d4d67d2a5a13d69b8225003d2ac3c78ab2 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 10:44:28 -0700 Subject: [PATCH 004/166] s/ports/targets/ --- text/0000-target-tier-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 186f7e61988..f8d3ffa3849 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -227,8 +227,8 @@ Eventually, as more targets seek tier 1 status, we may want to document more criteria used to evaluate requirements such as "long-term viability of the target". We should also update these requirements if corner cases arise. -Some of our existing ports may not meet all of these criteria today. We may -wish to audit existing ports against these criteria, but this RFC does not +Some of our existing targets may not meet all of these criteria today. We may +wish to audit existing targets against these criteria, but this RFC does not constitute a commitment to do so in a timely fashion. This RFC should not serve as the canonical home of the most up-to-date version From a4e88d8348d90baec7577890250a0e8e3d2fd72f Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 10:54:02 -0700 Subject: [PATCH 005/166] Clarify "broader ecosystem" --- text/0000-target-tier-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index f8d3ffa3849..bbb62185c2a 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -70,8 +70,8 @@ place minimal requirements on the introduction of targets. - Tier 3 targets must use naming consistent with any existing targets; for instance, a target for a similar CPU or OS should not gratuitously use an inconsistent name for that CPU or OS. Targets should normally use the same - names as used elsewhere in the broader ecosystem (such as in other - toolchains), unless they have a very good reason to diverge. + names as used elsewhere in the broader ecosystem beyond Rust (such as in + other toolchains), unless they have a very good reason to diverge. - Tier 3 targets may have unusual requirements to build or use, but must not create legal issues for the Rust project or for developers who work on those targets. From 13da5e1fd68a4052419f8c2e843637abca2fdb4c Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 11:01:31 -0700 Subject: [PATCH 006/166] Cover targets leaving portions of the standard library `unimplemented!()` --- text/0000-target-tier-policy.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index bbb62185c2a..f896dc44be8 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -75,6 +75,12 @@ place minimal requirements on the introduction of targets. - Tier 3 targets may have unusual requirements to build or use, but must not create legal issues for the Rust project or for developers who work on those targets. +- Tier 3 targets should attempt to implement as much of the standard library as + possible, but may leave some code `unimplemented!()`, whether because the + target makes it impossible to implement or challenging to implement. The + authors of pull requests are not obligated to avoid calling any portions of + the standard library on the basis of a tier 3 target not implementing those + portions. - Where possible, tier 3 targets may wish to provide documentation for the Rust community for how to build and run tests for the platform, ideally using emulation. @@ -117,6 +123,9 @@ the target will not block forward progress of the Rust project. should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance their documentation of the target. +- Tier 2 targets must not leave any significant portions of `core` or the + standard library `unimplemented!()`, unless they cannot possibly be supported + on the target. - The target must build reliably in CI. - Building the target must not take substantially longer than other targets. - Tier 2 targets must support building on the existing targets used for CI From b3152e8dbe93c4c041e38ffad9b20dbe5b6aafcc Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 11:18:36 -0700 Subject: [PATCH 007/166] Add a note about the extent of tool support for targets --- text/0000-target-tier-policy.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index f896dc44be8..216b881c3ed 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -147,7 +147,9 @@ the target will not block forward progress of the Rust project. Note: some tier 2 platforms additionally have binaries built to run on them as a host (such as `rustc` and `cargo`). Such a platform must meet all the requirements above, and must additionally get the compiler and infrastructure -team to approve the building of host tools. +team to approve the building of host tools. Depending on the target and its +capabilities, this may include only `rustc` and `cargo`, or may include +additional tools such as `clippy` and `rustfmt`. ## Tier 1 target policy From 178b102a619038e36391cc5bd5ca6ff7a5506bd6 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 11:19:33 -0700 Subject: [PATCH 008/166] Consistently use "target" rather than "platform" --- text/0000-target-tier-policy.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 216b881c3ed..8a0ac9dcdb0 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -82,7 +82,7 @@ place minimal requirements on the introduction of targets. the standard library on the basis of a tier 3 target not implementing those portions. - Where possible, tier 3 targets may wish to provide documentation for the Rust - community for how to build and run tests for the platform, ideally using + community for how to build and run tests for the target, ideally using emulation. - Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, @@ -93,7 +93,7 @@ place minimal requirements on the introduction of targets. - If a tier 3 target shows no signs of activity and has not built for some time, and removing it would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to people who have - previously worked on the platform, to check potential interest. + previously worked on the target, to check potential interest. ## Tier 2 target policy @@ -117,7 +117,7 @@ the target will not block forward progress of the Rust project. every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target. - Where possible, tier 2 targets should provide documentation for the Rust - community for how to build and run tests for the platform, ideally using + community for how to build and run tests for the target, ideally using emulation. - The target development team should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community @@ -140,12 +140,12 @@ the target will not block forward progress of the Rust project. target, and should fix any test failures in a reasonably timely fashion. - A tier 2 target may be demoted or removed if it no longer meets these requirements. Any proposal for demotion or removal will be CCed to people who - have previously worked on the platform, and will be communicated widely to - the Rust community before being dropped from a stable release. + have previously worked on the target, and will be communicated widely to the + Rust community before being dropped from a stable release. - All tier 3 requirements apply. -Note: some tier 2 platforms additionally have binaries built to run on them as -a host (such as `rustc` and `cargo`). Such a platform must meet all the +Note: some tier 2 targets additionally have binaries built to run on them as a +host (such as `rustc` and `cargo`). Such a target must meet all the requirements above, and must additionally get the compiler and infrastructure team to approve the building of host tools. Depending on the target and its capabilities, this may include only `rustc` and `cargo`, or may include @@ -177,8 +177,8 @@ target. We hold tier 1 targets to our highest standard of requirements. such resources to the Rust project, to the satisfaction and approval of the Rust infrastructure team. - Tier 1 targets must provide documentation for the Rust community for how to - build and run tests for the platform, using emulation if possible, or - dedicated hardware if necessary. + build and run tests for the target, using emulation if possible, or dedicated + hardware if necessary. - A tier 1 target may be demoted or removed if it no longer meets these requirements. Any proposal for demotion or removal will be communicated widely to the Rust community, both when initially proposed and before being From 53628f811bd3fe4ec41fb031a71a74745a6927aa Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 12:15:59 -0700 Subject: [PATCH 009/166] Elaborate on "must not break any existing target" Also explain a common case where this may come up. --- text/0000-target-tier-policy.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 8a0ac9dcdb0..f4842481178 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -89,7 +89,14 @@ place minimal requirements on the introduction of targets. do not post comments (automated or manual) on a PR that suggests a block on the PR based on the target. (A PR author may choose to help with a tier 3 target but is not required to.) -- Patches adding or updating tier 3 targets must not break any existing target. +- Patches adding or updating tier 3 targets must not break any existing tier 2 + or tier 1 target, and must not break another tier 3 target without approval + of either the compiler team or the maintainers of the other tier 3 target. + - In particular, this may come up when working on closely related targets, + such as variations of the same architecture with different features. Avoid + introducing unconditional uses of features that another variation of the + target may not have; use conditional compilation or runtime detection, as + appropriate, to let each target run code supported by that target. - If a tier 3 target shows no signs of activity and has not built for some time, and removing it would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to people who have From f88d05ac623f46d3d906af926b815bccd0ff5477 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 12:20:08 -0700 Subject: [PATCH 010/166] Formatting improvements --- text/0000-target-tier-policy.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index f4842481178..dea7134d224 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -7,7 +7,7 @@ [summary]: #summary We should have an official, objective policy for adding new (tier 3) targets, -and for raising targets to tier 2 (with rustup builds) or even tier 1. +and for raising targets to tier 2 (with `rustup` builds) or even tier 1. # Motivation [motivation]: #motivation @@ -19,12 +19,12 @@ 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 policy for target tiers. People not only don't know, they don't know who -to ask or where to start. +(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 policy for target tiers. People not only don't know, they +don't know who to ask or where to start. -(See https://forge.rust-lang.org/platform-support.html for more information +(See for more information about targets and tiers.) # Guide-level explanation @@ -45,7 +45,7 @@ maintainers of the target, to demonstrate value and to minimize any disruptions to ongoing Rust development. The policy sections of this RFC should be posted on -https://forge.rust-lang.org/ in a "Target Tier Policy" section. + in a "Target Tier Policy" section. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -211,7 +211,7 @@ targets. [prior-art]: #prior-art This attempts to formalize and document Rust policy around targets and -architectures. https://forge.rust-lang.org/release/platform-support.html +architectures. documents some of that policy. Future expansions of such policy may find requirements from other communities From 43b4891549456a09501972b0c6bd1c9f4e64eab3 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 12:27:52 -0700 Subject: [PATCH 011/166] Discuss alternative means of handling team consensus --- text/0000-target-tier-policy.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index dea7134d224..fb726fca1f7 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -206,6 +206,14 @@ The set of approving teams for each tier arose out of discussion with the various teams involved with aspects of the Rust project impacted by new targets. +Policies that require the approval of multiple teams could instead require a +core team approval. This would have the advantage of reducing the number of +people involved in the final approval, but would put more coordination effort +on the core team and the various team leads to ensure that the individual teams +approve. As another alternative, we could separate the individual team +approvals (into separate issues or separate rfcbot polls), to simplify checking +for consensus and reduce diffusion of responsibility; however, this could also +increase the resulting complexity and result in discussions in multiple places. # Prior art [prior-art]: #prior-art From 3a3b3f831a19c1d5defee47b6c3f953ebbdf553b Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 13:34:26 -0700 Subject: [PATCH 012/166] Explain subjective requirements like "substantial, widespread interest" --- text/0000-target-tier-policy.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index fb726fca1f7..29109865fdf 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -173,9 +173,10 @@ target. We hold tier 1 targets to our highest standard of requirements. target, and the additional work of supporting the target. - Tier 1 targets must have substantial, widespread interest within the developer community, and must serve the ongoing needs of multiple production - users of Rust across multiple organizations or projects. A tier 1 target may - be demoted or removed if it becomes obsolete or no longer meets this - requirement. + users of Rust across multiple organizations or projects. These requirements + are subjective, and determined by consensus of the approving teams. A tier 1 + target may be demoted or removed if it becomes obsolete or no longer meets + this requirement. - The target must build and pass tests reliably in CI. - Building the target and running the testsuite for the target must not take substantially longer than other targets. From e52dac14bea6a2f71564201ca3c28a67d0cb6833 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 13:36:21 -0700 Subject: [PATCH 013/166] Rephrase link to platform support page, and provide link text --- text/0000-target-tier-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 29109865fdf..85f95c74927 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -220,8 +220,8 @@ increase the resulting complexity and result in discussions in multiple places. [prior-art]: #prior-art This attempts to formalize and document Rust policy around targets and -architectures. -documents some of that policy. +architectures. Some requirements of such a policy appear on the [Rust Platform +Support page](https://forge.rust-lang.org/release/platform-support.html). Future expansions of such policy may find requirements from other communities useful as examples, such as Debian's [arch From 159dbf15722c0ec138ccd6d184592e167f3d5998 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 13:41:58 -0700 Subject: [PATCH 014/166] Clarify approval of CI-related requirements. --- text/0000-target-tier-policy.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 85f95c74927..232e789cdba 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -111,8 +111,8 @@ the target will not block forward progress of the Rust project. - Any new tier 2 target requires compiler team approval based on these requirements. - In addition, the infrastructure team must approve the integration of the - target into CI, and the CI-related requirements. This review and approval - will typically take place in the PR adding the target to CI. + target into CI, and the tier 2 CI-related requirements. This review and + approval will typically take place in the PR adding the target to CI. - A tier 2 target must have value to people other than its maintainers. - Any new tier 2 target must have a designated team of developers on call to consult on target-specific build-breaking issues, or if necessary to develop @@ -167,8 +167,8 @@ target. We hold tier 1 targets to our highest standard of requirements. - Any new tier 1 target requires compiler team approval based on these requirements. - In addition, the infrastructure team must approve the integration of the - target into CI, and the CI-related requirements. This review and approval - will typically take place in the PR adding the target to CI. + target into CI, and the tier 1 CI-related requirements. This review and + approval will typically take place in the PR adding the target to CI. - In addition, the release team must approve the long-term viability of the target, and the additional work of supporting the target. - Tier 1 targets must have substantial, widespread interest within the From 435cc9b3f99ff8f6a180fa2d25e0dc53cf2b00ff Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 14:23:21 -0700 Subject: [PATCH 015/166] Update link to avoid redirect --- text/0000-target-tier-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 232e789cdba..a1d532921ca 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -24,8 +24,8 @@ occasionally ask what it would take to add a new tier 1 target. The Rust project has no clear policy for target tiers. People not only don't know, they don't know who to ask or where to start. -(See for more information -about targets and tiers.) +(See for more +information about targets and tiers.) # Guide-level explanation [guide-level-explanation]: #guide-level-explanation From 5a373672440a60e5491f55d6597eb4c665dcbbcc Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 14:23:32 -0700 Subject: [PATCH 016/166] Drop unnecessary parentheses --- text/0000-target-tier-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index a1d532921ca..6889400edbc 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -24,8 +24,8 @@ occasionally ask what it would take to add a new tier 1 target. The Rust project has no clear policy for target tiers. People not only don't know, they don't know who to ask or where to start. -(See for more -information about targets and tiers.) +See for more +information about targets and tiers. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation From d33d656785597342a2d46aa467fa98766f0420cd Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 14:24:24 -0700 Subject: [PATCH 017/166] Move note about posting this policy out of the guide-level explanation --- text/0000-target-tier-policy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 6889400edbc..d967f483e07 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -27,6 +27,9 @@ don't know who to ask or where to start. See for more information about targets and tiers. +The policy sections of this RFC should be posted on + in a "Target Tier Policy" section. + # Guide-level explanation [guide-level-explanation]: #guide-level-explanation @@ -44,9 +47,6 @@ breaking the target. Thus, these tiers require commensurate efforts from the maintainers of the target, to demonstrate value and to minimize any disruptions to ongoing Rust development. -The policy sections of this RFC should be posted on - in a "Target Tier Policy" section. - # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From 4a87994a050e8c5f66a272b9c70ae668fb07c9b1 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 14:28:44 -0700 Subject: [PATCH 018/166] Expand introduction for reference-level explanation --- text/0000-target-tier-policy.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index d967f483e07..14c51eeca61 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -50,7 +50,13 @@ to ongoing Rust development. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation -Requirements for each tier: +Rust targets fall into three "tiers" of support: +- Tier 3 targets, which provide no guarantees of support. +- Tier 2 targets, which will always build but not pass tests. +- Tier 1 targets, which will always build and pass tests. + +This policy defines the requirements for accepting a proposed target at a given +level of support. ## Tier 3 target policy From 22424e4ceade8390d04f33cbe42c2b4da7199e86 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 15:34:16 -0700 Subject: [PATCH 019/166] Consistently use more precise language "may contact" for contacting teams --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 14c51eeca61..3f991192363 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -67,7 +67,7 @@ place minimal requirements on the introduction of targets. always use their own best judgment regarding the quality of work, and the suitability of a target for the Rust project. - If a reviewer wishes to consult a broader team for additional guidance, they - should contact the compiler team. + may contact the compiler team. - If a proposed target or target-specific patch substantially changes code shared with other targets (not just target-specific code), the reviewer should consult the compiler team. From 522d3a4f41ca126e745fe5481a0a6819d3f4ebb5 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 15:35:18 -0700 Subject: [PATCH 020/166] Make "at least 2 developers" a hard requirement for tier 2 targets --- text/0000-target-tier-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 3f991192363..2865c39be80 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -122,8 +122,8 @@ the target will not block forward progress of the Rust project. - A tier 2 target must have value to people other than its maintainers. - Any new tier 2 target must have a designated team of developers on call to consult on target-specific build-breaking issues, or if necessary to develop - target-specific language or library implementation details. (This team should - in almost all cases have at least 2 developers.) + target-specific language or library implementation details. This team must + have at least 2 developers. - The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers may be expected to not gratuitously break a tier 2 target, but are not expected to become experts in From 8b5247297d6a1431f24d1b5198922ca53506d105 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 15:41:35 -0700 Subject: [PATCH 021/166] Clarify that new tier 2 targets must cross-compile --- text/0000-target-tier-policy.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 2865c39be80..3ab5df1899e 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -142,7 +142,9 @@ the target will not block forward progress of the Rust project. - The target must build reliably in CI. - Building the target must not take substantially longer than other targets. - Tier 2 targets must support building on the existing targets used for CI - infrastructure. + infrastructure. In particular, new tier 2 targets must support + cross-compiling, and must not require using the target as the host for + builds. - Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. In particular, do not post comments (automated or manual) on a PR that From ea1549c0596c0cb85219628db151f35e441806a0 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 15:44:14 -0700 Subject: [PATCH 022/166] More precise language: s/shall/must/ --- text/0000-target-tier-policy.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 3ab5df1899e..dbdefc71ddc 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -188,10 +188,10 @@ target. We hold tier 1 targets to our highest standard of requirements. - The target must build and pass tests reliably in CI. - Building the target and running the testsuite for the target must not take substantially longer than other targets. -- If running the testsuite requires additional infrastructure (such as systems - running the target), the target development team shall arrange to provide - such resources to the Rust project, to the satisfaction and approval of the - Rust infrastructure team. +- If running the testsuite requires additional infrastructure (such as physical + systems running the target), the target development team must arrange to + provide such resources to the Rust project, to the satisfaction and approval + of the Rust infrastructure team. - Tier 1 targets must provide documentation for the Rust community for how to build and run tests for the target, using emulation if possible, or dedicated hardware if necessary. From b30bb0868c2a1e7764c80903565803244156ead8 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 15:53:01 -0700 Subject: [PATCH 023/166] Explain that targets may be temporarily disabled in nightlies --- text/0000-target-tier-policy.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index dbdefc71ddc..cdb1b36cf26 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -157,6 +157,17 @@ the target will not block forward progress of the Rust project. requirements. Any proposal for demotion or removal will be CCed to people who have previously worked on the target, and will be communicated widely to the Rust community before being dropped from a stable release. + - In some circumstances, especially if the target maintainer team does not + respond in a timely fashion, Rust teams may land pull requests that + temporarily disable some targets in the nightly compiler, in order to + implement a feature not yet supported by those targets. (As an example, + this happened when introducing the 128-bit types `u128` and `i128`.) Such a + pull request will include notification and coordination with the + maintainers of such targets. The maintainers of such targets will then be + expected to implement the corresponding target-specific support in order to + re-enable the target. If the maintainers of such targets cannot provide + such support in time for the next stable release, this may result in + demoting or removing the targets. - All tier 3 requirements apply. Note: some tier 2 targets additionally have binaries built to run on them as a From cc7c1a54af81d0ea75a3bbceb193608cd9f1f011 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 22:50:21 -0700 Subject: [PATCH 024/166] Explicitly define terms like "target development team" --- text/0000-target-tier-policy.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index cdb1b36cf26..2cf14235d38 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -120,8 +120,9 @@ the target will not block forward progress of the Rust project. target into CI, and the tier 2 CI-related requirements. This review and approval will typically take place in the PR adding the target to CI. - A tier 2 target must have value to people other than its maintainers. -- Any new tier 2 target must have a designated team of developers on call to - consult on target-specific build-breaking issues, or if necessary to develop +- Any new tier 2 target must have a designated team of developers (the "target + development team" or "target maintainers") on call to consult on + target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers. - The target must not place undue burden on Rust developers not specifically From 97620fa8bf6a1cd3f52e68af7ef2e45693f89459 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 22:50:48 -0700 Subject: [PATCH 025/166] Make it a hard requirement to document how to build and run tests --- text/0000-target-tier-policy.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 2cf14235d38..e6f911bd691 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -130,9 +130,8 @@ the target will not block forward progress of the Rust project. gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target. -- Where possible, tier 2 targets should provide documentation for the Rust - community for how to build and run tests for the target, ideally using - emulation. +- Tier 2 targets must provide documentation for the Rust community for how to + build and run tests for the target (ideally using emulation). - The target development team should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance their documentation of the From 7ec7ff19753ca83eb18497bf6ae146d009b779d5 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 22:51:59 -0700 Subject: [PATCH 026/166] Define "CI" on first use --- text/0000-target-tier-policy.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index e6f911bd691..d5abd41c43f 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -117,8 +117,9 @@ the target will not block forward progress of the Rust project. - Any new tier 2 target requires compiler team approval based on these requirements. - In addition, the infrastructure team must approve the integration of the - target into CI, and the tier 2 CI-related requirements. This review and - approval will typically take place in the PR adding the target to CI. + target into Continuous Integration (CI), and the tier 2 CI-related + requirements. This review and approval will typically take place in the PR + adding the target to CI. - A tier 2 target must have value to people other than its maintainers. - Any new tier 2 target must have a designated team of developers (the "target development team" or "target maintainers") on call to consult on @@ -186,8 +187,9 @@ target. We hold tier 1 targets to our highest standard of requirements. - Any new tier 1 target requires compiler team approval based on these requirements. - In addition, the infrastructure team must approve the integration of the - target into CI, and the tier 1 CI-related requirements. This review and - approval will typically take place in the PR adding the target to CI. + target into Continuous Integration (CI), and the tier 1 CI-related + requirements. This review and approval will typically take place in the PR + adding the target to CI. - In addition, the release team must approve the long-term viability of the target, and the additional work of supporting the target. - Tier 1 targets must have substantial, widespread interest within the From 4dcf8d8d0e172a35fdaa66a017b9afd06e27232f Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 22:53:50 -0700 Subject: [PATCH 027/166] Note up front that the tier requirements are cumulative --- text/0000-target-tier-policy.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index d5abd41c43f..1648d08b3a6 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -58,6 +58,9 @@ Rust targets fall into three "tiers" of support: This policy defines the requirements for accepting a proposed target at a given level of support. +Each tier builds on all the requirements from the previous tier, unless +overridden by a stronger requirement. + ## Tier 3 target policy At this tier, the Rust project provides no official support for a target, so we From 7d41f4ec58b00c3eb204c7a25291fc31a5e669dd Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 23:04:57 -0700 Subject: [PATCH 028/166] Note up front about approving teams and subjective judgment --- text/0000-target-tier-policy.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 1648d08b3a6..33be9692280 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -61,6 +61,13 @@ level of support. Each tier builds on all the requirements from the previous tier, unless overridden by a stronger requirement. +The policy for each tier also documents the Rust governance teams that must +approve the addition of any target at that tier. Those teams are responsible +for reviewing and evaluating the target, based on these requirements and their +own judgment. Those teams may apply additional requirements, including +subjective requirements, such as to deal with issues not foreseen by this +policy. (Such requirements may subsequently motivate additions of this policy.) + ## Tier 3 target policy At this tier, the Rust project provides no official support for a target, so we From 395f5f1625fadd9beaa55b562004e161bd334705 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sat, 11 Jul 2020 23:42:54 -0700 Subject: [PATCH 029/166] Discuss baseline expectations for CPU features, OS versions/features, 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. --- text/0000-target-tier-policy.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 33be9692280..83af642fdb2 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -147,6 +147,29 @@ the target will not block forward progress of the Rust project. should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance their documentation of the target. +- The target must document its baseline expectations for CPU features, + operating system versions or features, runtime environment versions or + features, or similar. +- If introducing a new tier 2 or higher target that is identical to an existing + Rust target except for the baseline expectations for CPU features, operating + system versions or features, runtime environment versions or features, or + similar, then the proposed target must document to the satisfaction of the + approving teams why the specific difference in baseline expectations provides + sufficient value to justify a separate target. + - Note that in some cases, based on the usage of existing targets within the + Rust community, Rust developers or a target development team may wish to + modify the baseline expectations of a target, or split an existing target + into multiple targets with different baseline expectations. A proposal to + do so will be treated similarly to the analogous promotion, demotion, or + removal of a target, according to this policy, with the same team approvals + required. + - For instance, if an OS version has become obsolete and unsupported, a + target for that OS may raise its baseline expectations for OS version + (treated as though removing a subset of the target), or a target for that + OS may split out support for older OS versions into a lower-tier target + (treated as though demoting a subset of the target, and requiring + justification for a new target at a lower tier for the older OS + versions). - Tier 2 targets must not leave any significant portions of `core` or the standard library `unimplemented!()`, unless they cannot possibly be supported on the target. From 523c8ea23c17fab8bc7ea2da692a056293ecaad2 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 00:04:56 -0700 Subject: [PATCH 030/166] Add a (subjective) requirement to not disable an excessive number of tests --- text/0000-target-tier-policy.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 83af642fdb2..fbe73d3a78b 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -232,6 +232,8 @@ target. We hold tier 1 targets to our highest standard of requirements. target may be demoted or removed if it becomes obsolete or no longer meets this requirement. - The target must build and pass tests reliably in CI. + - The target must not disable an excessive number of tests or pieces of tests + in the testsuite in order to do so. This is a subjective requirement. - Building the target and running the testsuite for the target must not take substantially longer than other targets. - If running the testsuite requires additional infrastructure (such as physical From c32f79a6694318c860b37d9cc587b5468736b56a Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 00:05:50 -0700 Subject: [PATCH 031/166] Add a tier 1 requirement discussing implementation of the standard library --- text/0000-target-tier-policy.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index fbe73d3a78b..8bb48e6a643 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -234,6 +234,10 @@ target. We hold tier 1 targets to our highest standard of requirements. - The target must build and pass tests reliably in CI. - The target must not disable an excessive number of tests or pieces of tests in the testsuite in order to do so. This is a subjective requirement. +- The target must provide as much of the Rust standard library as is feasible + and appropriate to provide. For instance, if the target has a standard memory + allocator, it must provide an implementation of `alloc` and the associated + data structures. - Building the target and running the testsuite for the target must not take substantially longer than other targets. - If running the testsuite requires additional infrastructure (such as physical From 1b28be0783ef331055c47f4a2cc88fb58383f44d Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 00:15:19 -0700 Subject: [PATCH 032/166] Hard requirement to discuss changes to shared code with the compiler team --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 8bb48e6a643..49d7071486a 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -80,7 +80,7 @@ place minimal requirements on the introduction of targets. may contact the compiler team. - If a proposed target or target-specific patch substantially changes code shared with other targets (not just target-specific code), the reviewer - should consult the compiler team. + must consult the compiler team. - If the proposer of a target wishes to appeal the rejection of a target, they may contact the compiler team. - Tier 3 targets must use naming consistent with any existing targets; for From 29c6c5e1adbffc443667e98101c387fafd4f01a6 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 00:16:15 -0700 Subject: [PATCH 033/166] Meet the requirements before proposing the target --- text/0000-target-tier-policy.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 49d7071486a..7591f88f3d5 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -68,6 +68,15 @@ own judgment. Those teams may apply additional requirements, including subjective requirements, such as to deal with issues not foreseen by this policy. (Such requirements may subsequently motivate additions of this policy.) +Before filing an issue or pull request (PR) to introduce or promote a target, +the target should already meet the corresponding tier requirements. (This does +not preclude a target's development team using issues to track requirements +that have not yet been met, as appropriate; however, before officially +proposing the introduction or promotion of a target, it should meet all of the +necessary requirements.) A target proposal is encouraged to quote the +corresponding requirements verbatim as part of explaining how the target meets +those requirements. + ## Tier 3 target policy At this tier, the Rust project provides no official support for a target, so we From 39afc671ed31d4a94f9f02d9a436ff19caa92f6c Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 00:23:13 -0700 Subject: [PATCH 034/166] Clarifications about baseline expectations --- text/0000-target-tier-policy.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 7591f88f3d5..9813347a950 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -156,14 +156,14 @@ the target will not block forward progress of the Rust project. should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance their documentation of the target. -- The target must document its baseline expectations for CPU features, - operating system versions or features, runtime environment versions or - features, or similar. +- The target must document its baseline expectations for the features or + versions of CPUs, operating systems, libraries, runtime environments, and + similar. - If introducing a new tier 2 or higher target that is identical to an existing - Rust target except for the baseline expectations for CPU features, operating - system versions or features, runtime environment versions or features, or - similar, then the proposed target must document to the satisfaction of the - approving teams why the specific difference in baseline expectations provides + Rust target except for the baseline expectations for the features or versions + of CPUs, operating systems, libraries, runtime environments, and similar, + then the proposed target must document to the satisfaction of the approving + teams why the specific difference in baseline expectations provides sufficient value to justify a separate target. - Note that in some cases, based on the usage of existing targets within the Rust community, Rust developers or a target development team may wish to @@ -174,11 +174,11 @@ the target will not block forward progress of the Rust project. required. - For instance, if an OS version has become obsolete and unsupported, a target for that OS may raise its baseline expectations for OS version - (treated as though removing a subset of the target), or a target for that - OS may split out support for older OS versions into a lower-tier target - (treated as though demoting a subset of the target, and requiring - justification for a new target at a lower tier for the older OS - versions). + (treated as though removing a target corresponding to the older + versions), or a target for that OS may split out support for older OS + versions into a lower-tier target (treated as though demoting a target + corresponding to the older versions, and requiring justification for a + new target at a lower tier for the older OS versions). - Tier 2 targets must not leave any significant portions of `core` or the standard library `unimplemented!()`, unless they cannot possibly be supported on the target. From 5f839e3725dee00f42abb0668752dcfce2fe9ae6 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 00:33:04 -0700 Subject: [PATCH 035/166] Tier 2 targets may be required to pass basic smoke tests --- text/0000-target-tier-policy.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 9813347a950..a4ba1687dba 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -183,6 +183,11 @@ the target will not block forward progress of the Rust project. standard library `unimplemented!()`, unless they cannot possibly be supported on the target. - The target must build reliably in CI. +- The approving teams may additionally require that a subset of tests pass in + CI, such as enough to build a functional "hello world" program, or equivalent + "smoke tests". In particular, this requirement may apply if the target builds + host tools, or if the tests in question provide substantial value via early + detection of critical problems. - Building the target must not take substantially longer than other targets. - Tier 2 targets must support building on the existing targets used for CI infrastructure. In particular, new tier 2 targets must support From 2fdcfe1992742e5b0225330882ebf59e5442acab Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 00:46:15 -0700 Subject: [PATCH 036/166] Move approving teams out of the bullet lists of requirements This helps ensure that the bullet lists contain only requirements, so that they can be used as checklists, and quoted for point-by-point explanations within target proposals. --- text/0000-target-tier-policy.md | 53 ++++++++++++++++++--------------- 1 file changed, 29 insertions(+), 24 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index a4ba1687dba..4df7d7c8f84 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -82,16 +82,18 @@ those requirements. At this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets. -- No central decision is required to add a new tier 3 target. Reviewers may - always use their own best judgment regarding the quality of work, and the - suitability of a target for the Rust project. -- If a reviewer wishes to consult a broader team for additional guidance, they - may contact the compiler team. -- If a proposed target or target-specific patch substantially changes code - shared with other targets (not just target-specific code), the reviewer - must consult the compiler team. -- If the proposer of a target wishes to appeal the rejection of a target, they - may contact the compiler team. +No central decision is required to add a new tier 3 target. Reviewers may +always use their own best judgment regarding the quality of work, and the +suitability of a target for the Rust project. + +If a reviewer wishes to consult a broader team for additional guidance, they +may contact the compiler team. A proposed target or target-specific patch that +substantially changes code shared with other targets (not just target-specific +code) requires the approval of the compiler team. + +If the proposer of a target wishes to appeal the rejection of a target, they +may contact the compiler team. + - Tier 3 targets must use naming consistent with any existing targets; for instance, a target for a similar CPU or OS should not gratuitously use an inconsistent name for that CPU or OS. Targets should normally use the same @@ -133,12 +135,13 @@ At this tier, the Rust project guarantees that a target builds, and will reject patches that fail to build on a target. Thus, we place requirements that ensure the target will not block forward progress of the Rust project. -- Any new tier 2 target requires compiler team approval based on these - requirements. -- In addition, the infrastructure team must approve the integration of the - target into Continuous Integration (CI), and the tier 2 CI-related - requirements. This review and approval will typically take place in the PR - adding the target to CI. +Any new tier 2 target requires compiler team approval based on these +requirements. + +In addition, the infrastructure team must approve the integration of the target +into Continuous Integration (CI), and the tier 2 CI-related requirements. This +review and approval may take place in a PR adding the target to CI. + - A tier 2 target must have value to people other than its maintainers. - Any new tier 2 target must have a designated team of developers (the "target development team" or "target maintainers") on call to consult on @@ -231,14 +234,16 @@ At this tier, the Rust project guarantees that a target builds and passes all tests, and will reject patches that fail to build or pass the testsuite on a target. We hold tier 1 targets to our highest standard of requirements. -- Any new tier 1 target requires compiler team approval based on these - requirements. -- In addition, the infrastructure team must approve the integration of the - target into Continuous Integration (CI), and the tier 1 CI-related - requirements. This review and approval will typically take place in the PR - adding the target to CI. -- In addition, the release team must approve the long-term viability of the - target, and the additional work of supporting the target. +Any new tier 1 target requires compiler team approval based on these +requirements. + +In addition, the infrastructure team must approve the integration of the target +into Continuous Integration (CI), and the tier 1 CI-related requirements. This +review and approval may take place in a PR adding the target to CI. + +In addition, the release team must approve the long-term viability of the +target, and the additional work of supporting the target. + - Tier 1 targets must have substantial, widespread interest within the developer community, and must serve the ongoing needs of multiple production users of Rust across multiple organizations or projects. These requirements From 3c0dc668e063148b61aca16fe1542a30d6fd9b0b Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 00:49:08 -0700 Subject: [PATCH 037/166] Move up the note about human judgment and "spirit of the requirements" Add it to the introduction of the requirements, rather than listing it as a "drawback". --- text/0000-target-tier-policy.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 4df7d7c8f84..5051abcff28 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -68,6 +68,10 @@ own judgment. Those teams may apply additional requirements, including subjective requirements, such as to deal with issues not foreseen by this policy. (Such requirements may subsequently motivate additions of this policy.) +While these criteria attempt to document the policy, that policy still involves +human judgment. Targets must fulfill the spirit of the requirements as well, as +determined by the judgment of the approving teams. + Before filing an issue or pull request (PR) to introduce or promote a target, the target should already meet the corresponding tier requirements. (This does not preclude a target's development team using issues to track requirements @@ -272,13 +276,6 @@ target, and the additional work of supporting the target. dropped from a stable release. - All tier 2 requirements apply. -# Drawbacks -[drawbacks]: #drawbacks - -While these criteria attempt to document the policy, that policy still involves -human judgment. Targets must fulfill the spirit of the requirements as well, as -determined by the judgment of the approving teams. - # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives From a067660daf537f5f840ba32a52ab3ff9b79fad42 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 00:54:28 -0700 Subject: [PATCH 038/166] Update summary. Remove "objective". Actually summarize the RFC. --- text/0000-target-tier-policy.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 5051abcff28..a129bbe9797 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -6,8 +6,9 @@ # Summary [summary]: #summary -We should have an official, objective policy for adding new (tier 3) targets, -and for raising targets to tier 2 (with `rustup` builds) or even tier 1. +We should have an official policy for adding new tier 3 targets, and for +raising targets to tier 2 (with `rustup` builds) or even tier 1. This RFC +codifies the requirements for targets at each tier. # Motivation [motivation]: #motivation From e43096a18b597c1585bafe53f58abe6f84d3ce03 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 01:06:39 -0700 Subject: [PATCH 039/166] Add precedents for tiered target support --- text/0000-target-tier-policy.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index a129bbe9797..5cf5fff2c4f 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -305,6 +305,13 @@ useful as examples, such as Debian's [arch policy](https://release.debian.org/bullseye/arch_policy.html) and [archive criteria](https://ftp-master.debian.org/archive-criteria.html). +Other precedents for tiered target support include [Firefox's supported build +targets](https://firefox-source-docs.mozilla.org/build/buildsystem/supported-configurations.html), +[node.js supported +platforms](https://github.com/nodejs/node/blob/master/BUILDING.md#supported-platforms), +and [GHC's platform +support](https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms). + # Unresolved questions [unresolved-questions]: #unresolved-questions From 2ca6bf388cc516f0ef3630b8e9d95ef6e06ca69c Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 01:19:21 -0700 Subject: [PATCH 040/166] Elaborate on slow builds --- text/0000-target-tier-policy.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 5cf5fff2c4f..123ae6ac7cb 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -196,7 +196,10 @@ review and approval may take place in a PR adding the target to CI. "smoke tests". In particular, this requirement may apply if the target builds host tools, or if the tests in question provide substantial value via early detection of critical problems. -- Building the target must not take substantially longer than other targets. +- Building the target in CI must not take substantially longer than the current + slowest target in CI. This requirement is subjective, to be evaluated by the + infrastructure team, and will take the community importance of the target + into account. - Tier 2 targets must support building on the existing targets used for CI infrastructure. In particular, new tier 2 targets must support cross-compiling, and must not require using the target as the host for From f7f4c9e5c890c1bbf094306d2d1c1d282365af56 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 01:19:59 -0700 Subject: [PATCH 041/166] Simplify explanation of building in CI --- text/0000-target-tier-policy.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 123ae6ac7cb..295fd0bb284 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -200,10 +200,9 @@ review and approval may take place in a PR adding the target to CI. slowest target in CI. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target into account. -- Tier 2 targets must support building on the existing targets used for CI - infrastructure. In particular, new tier 2 targets must support - cross-compiling, and must not require using the target as the host for - builds. +- Tier 2 targets must support building on the existing CI infrastructure. In + particular, new tier 2 targets must support cross-compiling, and must not + require using the target as the host for builds. - Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. In particular, do not post comments (automated or manual) on a PR that From 8884f782883f3eb78ac8d02de0472a360dfda45b Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 01:25:47 -0700 Subject: [PATCH 042/166] Reword and unify notes about where this policy will live --- text/0000-target-tier-policy.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 295fd0bb284..b64285064a6 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -28,8 +28,9 @@ don't know who to ask or where to start. See for more information about targets and tiers. -The policy sections of this RFC should be posted on - in a "Target Tier Policy" section. +Once accepted, the policy sections of this RFC should be posted on + in a "Target Tier Policy" section; this RFC will +not be the canonical home of the up-to-date target tier policy. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation @@ -343,7 +344,3 @@ target". We should also update these requirements if corner cases arise. Some of our existing targets may not meet all of these criteria today. We may wish to audit existing targets against these criteria, but this RFC does not constitute a commitment to do so in a timely fashion. - -This RFC should not serve as the canonical home of the most up-to-date version -of this policy; the official policy should live on rust-lang.org and in -official documentation. From bf9aa88e2d4698a47044f5df810d949fb35b3211 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 01:28:07 -0700 Subject: [PATCH 043/166] Expand future possibilities --- text/0000-target-tier-policy.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index b64285064a6..9dee2ce8f83 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -344,3 +344,7 @@ target". We should also update these requirements if corner cases arise. Some of our existing targets may not meet all of these criteria today. We may wish to audit existing targets against these criteria, but this RFC does not constitute a commitment to do so in a timely fashion. + +Future enhancements to the target tier policy may introduce more detailed +requirements for supplying host tools for a target, or for supplying part or +all of the standard library. From da57e47796820fc4ad20e04181a3608a8f281c5a Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 01:33:35 -0700 Subject: [PATCH 044/166] Clarify requirements to provide build and test documentation Since the requirement is now identical for tier 2 and tier 1, drop the duplicate from tier 1. Tier 3 has a weaker requirement here, since cross-compilation support is not a hard requirement for tier 3, and since instructions for running tests may not be applicable if the target does not support running tests. --- text/0000-target-tier-policy.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 9dee2ce8f83..022df6bf58a 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -114,9 +114,11 @@ may contact the compiler team. authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions. -- Where possible, tier 3 targets may wish to provide documentation for the Rust - community for how to build and run tests for the target, ideally using - emulation. +- The target must provide documentation for the Rust community explaining how + to build for the target, using cross-compilation if possible. If the target + supports running tests (even if they do not pass), the documentation must + explain how to run tests for the target, using emulation if possible or + dedicated hardware if necessary. - Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that suggests a block on @@ -159,8 +161,10 @@ review and approval may take place in a PR adding the target to CI. gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target. -- Tier 2 targets must provide documentation for the Rust community for how to - build and run tests for the target (ideally using emulation). +- The target must provide documentation for the Rust community explaining how + to build for the target using cross-compilation, and explaining how to run + tests for the target, using emulation if possible or dedicated hardware if + necessary. - The target development team should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance their documentation of the @@ -271,9 +275,6 @@ target, and the additional work of supporting the target. systems running the target), the target development team must arrange to provide such resources to the Rust project, to the satisfaction and approval of the Rust infrastructure team. -- Tier 1 targets must provide documentation for the Rust community for how to - build and run tests for the target, using emulation if possible, or dedicated - hardware if necessary. - A tier 1 target may be demoted or removed if it no longer meets these requirements. Any proposal for demotion or removal will be communicated widely to the Rust community, both when initially proposed and before being From 1e98267ed6e491ab4cc3ba771ee3693afb82c000 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 01:40:57 -0700 Subject: [PATCH 045/166] Add a missing comma --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 022df6bf58a..d86a761519b 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -123,7 +123,7 @@ may contact the compiler team. other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that suggests a block on the PR based on the target. (A PR author may choose to help with a tier 3 - target but is not required to.) + target, but is not required to.) - Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. From 0ccaaffb8f6e352329f52340a59a1a23a2729e25 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 01:44:31 -0700 Subject: [PATCH 046/166] Move demotion/removal discussion out of bullet lists These are procedures the Rust community will follow, not specific requirements a target must meet before being proposed. Moving these out of the bullet lists simplifies using the lists as checklists for target proposals. --- text/0000-target-tier-policy.md | 49 +++++++++++++++++---------------- 1 file changed, 26 insertions(+), 23 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index d86a761519b..94b7d9bf7d8 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -132,10 +132,11 @@ may contact the compiler team. introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target. -- If a tier 3 target shows no signs of activity and has not built for some - time, and removing it would improve the quality of the Rust codebase, we may - post a PR to remove it; any such PR will be CCed to people who have - previously worked on the target, to check potential interest. + +If a tier 3 target shows no signs of activity and has not built for some time, +and removing it would improve the quality of the Rust codebase, we may post a +PR to remove it; any such PR will be CCed to people who have previously worked +on the target, to check potential interest. ## Tier 2 target policy @@ -216,21 +217,6 @@ review and approval may take place in a PR adding the target to CI. tests pass for a tier 2 target, even if notified that they fail.) - The target development team should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion. -- A tier 2 target may be demoted or removed if it no longer meets these - requirements. Any proposal for demotion or removal will be CCed to people who - have previously worked on the target, and will be communicated widely to the - Rust community before being dropped from a stable release. - - In some circumstances, especially if the target maintainer team does not - respond in a timely fashion, Rust teams may land pull requests that - temporarily disable some targets in the nightly compiler, in order to - implement a feature not yet supported by those targets. (As an example, - this happened when introducing the 128-bit types `u128` and `i128`.) Such a - pull request will include notification and coordination with the - maintainers of such targets. The maintainers of such targets will then be - expected to implement the corresponding target-specific support in order to - re-enable the target. If the maintainers of such targets cannot provide - such support in time for the next stable release, this may result in - demoting or removing the targets. - All tier 3 requirements apply. Note: some tier 2 targets additionally have binaries built to run on them as a @@ -240,6 +226,22 @@ team to approve the building of host tools. Depending on the target and its capabilities, this may include only `rustc` and `cargo`, or may include additional tools such as `clippy` and `rustfmt`. +A tier 2 target may be demoted or removed if it no longer meets these +requirements. Any proposal for demotion or removal will be CCed to people who +have previously worked on the target, and will be communicated widely to the +Rust community before being dropped from a stable release. + +In some circumstances, especially if the target maintainer team does not +respond in a timely fashion, Rust teams may land pull requests that temporarily +disable some targets in the nightly compiler, in order to implement a feature +not yet supported by those targets. (As an example, this happened when +introducing the 128-bit types `u128` and `i128`.) Such a pull request will +include notification and coordination with the maintainers of such targets. The +maintainers of such targets will then be expected to implement the +corresponding target-specific support in order to re-enable the target. If the +maintainers of such targets cannot provide such support in time for the next +stable release, this may result in demoting or removing the targets. + ## Tier 1 target policy At this tier, the Rust project guarantees that a target builds and passes all @@ -275,12 +277,13 @@ target, and the additional work of supporting the target. systems running the target), the target development team must arrange to provide such resources to the Rust project, to the satisfaction and approval of the Rust infrastructure team. -- A tier 1 target may be demoted or removed if it no longer meets these - requirements. Any proposal for demotion or removal will be communicated - widely to the Rust community, both when initially proposed and before being - dropped from a stable release. - All tier 2 requirements apply. +A tier 1 target may be demoted or removed if it no longer meets these +requirements. Any proposal for demotion or removal will be communicated widely +to the Rust community, both when initially proposed and before being dropped +from a stable release. + # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives From d1f08f9d463852ea67c3e1207489bb8118bc7b4c Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 01:49:47 -0700 Subject: [PATCH 047/166] Note that tier 1 direct removal is highly unlikely --- text/0000-target-tier-policy.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 94b7d9bf7d8..7edee072c83 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -279,10 +279,11 @@ target, and the additional work of supporting the target. of the Rust infrastructure team. - All tier 2 requirements apply. -A tier 1 target may be demoted or removed if it no longer meets these -requirements. Any proposal for demotion or removal will be communicated widely -to the Rust community, both when initially proposed and before being dropped -from a stable release. +A tier 1 target may be demoted if it no longer meets these requirements. Any +proposal for demotion or removal will be communicated widely to the Rust +community, both when initially proposed and before being dropped from a stable +release. A tier 1 target is highly unlikely to be directly removed without +first being demoted to tier 2 or tier 3. # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives From 571ab020efbf4cf3ee9b2d1376cc023bf3363842 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 01:58:38 -0700 Subject: [PATCH 048/166] Minor wording clarification about naming consistency --- text/0000-target-tier-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 7edee072c83..d9e84a1ef2d 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -101,8 +101,8 @@ If the proposer of a target wishes to appeal the rejection of a target, they may contact the compiler team. - Tier 3 targets must use naming consistent with any existing targets; for - instance, a target for a similar CPU or OS should not gratuitously use an - inconsistent name for that CPU or OS. Targets should normally use the same + instance, a target for the same CPU or OS as an existing Rust target should + use the same name for that CPU or OS. Targets should normally use the same names as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. - Tier 3 targets may have unusual requirements to build or use, but must not From 1c4bc2ac83aaa9b58a4a0a81717522cded45ae41 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 02:37:41 -0700 Subject: [PATCH 049/166] Change "on call" to "available" "on call" could potentially have undue connotations of response time expectations, analogous to having to wear a pager. --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index d9e84a1ef2d..335ad594580 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -153,7 +153,7 @@ review and approval may take place in a PR adding the target to CI. - A tier 2 target must have value to people other than its maintainers. - Any new tier 2 target must have a designated team of developers (the "target - development team" or "target maintainers") on call to consult on + development team" or "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers. From e386c26fdaab2a577c207bb234cbe29f6dba439a Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 02:40:11 -0700 Subject: [PATCH 050/166] Clean up wording to be less colloquial --- text/0000-target-tier-policy.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 335ad594580..f028003253e 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -158,10 +158,10 @@ review and approval may take place in a PR adding the target to CI. target-specific language or library implementation details. This team must have at least 2 developers. - The target must not place undue burden on Rust developers not specifically - concerned with that target. Rust developers may be expected to not - gratuitously break a tier 2 target, but are not expected to become experts in - every tier 2 target, and are not expected to provide target-specific - implementations for every tier 2 target. + concerned with that target. Rust developers are expected to not gratuitously + break a tier 2 target, but are not expected to become experts in every tier 2 + target, and are not expected to provide target-specific implementations for + every tier 2 target. - The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target, using emulation if possible or dedicated hardware if From d2e86f55eba7a77bcabe25b09fd5ac1c2e08d406 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 02:42:25 -0700 Subject: [PATCH 051/166] Relocate a note about the target development team --- text/0000-target-tier-policy.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index f028003253e..09040ab1c9c 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -157,6 +157,10 @@ review and approval may take place in a PR adding the target to CI. target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers. + - The target development team should not only fix target-specific issues, but + should use any such issue as an opportunity to educate the Rust community + about portability to their target, and enhance their documentation of the + target. - The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers are expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 @@ -166,10 +170,6 @@ review and approval may take place in a PR adding the target to CI. to build for the target using cross-compilation, and explaining how to run tests for the target, using emulation if possible or dedicated hardware if necessary. -- The target development team should not only fix target-specific issues, but - should use any such issue as an opportunity to educate the Rust community - about portability to their target, and enhance their documentation of the - target. - The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar. From c6dcb4e5ed8cb00c8cf309e97699a4e83f69ce74 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 02:47:43 -0700 Subject: [PATCH 052/166] Alternatives: concrete time requirements before introduction/promotion --- text/0000-target-tier-policy.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 09040ab1c9c..76f9a660acb 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -301,6 +301,9 @@ approvals (into separate issues or separate rfcbot polls), to simplify checking for consensus and reduce diffusion of responsibility; however, this could also increase the resulting complexity and result in discussions in multiple places. +We could introduce specific time requirements for the amount of time a target +must spend at a tier before becoming eligible for promotion to a higher tier. + # Prior art [prior-art]: #prior-art From ebdc7f02e87650e68139f6eb189120b860e5ed07 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 03:10:42 -0700 Subject: [PATCH 053/166] Unify terminology towards "target maintainers" instead of "target development team" --- text/0000-target-tier-policy.md | 53 ++++++++++++++++----------------- 1 file changed, 26 insertions(+), 27 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 76f9a660acb..d7e1dfc7901 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -76,12 +76,12 @@ determined by the judgment of the approving teams. Before filing an issue or pull request (PR) to introduce or promote a target, the target should already meet the corresponding tier requirements. (This does -not preclude a target's development team using issues to track requirements -that have not yet been met, as appropriate; however, before officially -proposing the introduction or promotion of a target, it should meet all of the -necessary requirements.) A target proposal is encouraged to quote the -corresponding requirements verbatim as part of explaining how the target meets -those requirements. +not preclude a target's maintainers using issues to track requirements that +have not yet been met, as appropriate; however, before officially proposing the +introduction or promotion of a target, it should meet all of the necessary +requirements.) A target proposal is encouraged to quote the corresponding +requirements verbatim as part of explaining how the target meets those +requirements. ## Tier 3 target policy @@ -153,11 +153,10 @@ review and approval may take place in a PR adding the target to CI. - A tier 2 target must have value to people other than its maintainers. - Any new tier 2 target must have a designated team of developers (the "target - development team" or "target maintainers") available to consult on - target-specific build-breaking issues, or if necessary to develop - target-specific language or library implementation details. This team must - have at least 2 developers. - - The target development team should not only fix target-specific issues, but + maintainers") available to consult on target-specific build-breaking issues, + or if necessary to develop target-specific language or library implementation + details. This team must have at least 2 developers. + - The target maintainers should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance their documentation of the target. @@ -180,7 +179,7 @@ review and approval may take place in a PR adding the target to CI. teams why the specific difference in baseline expectations provides sufficient value to justify a separate target. - Note that in some cases, based on the usage of existing targets within the - Rust community, Rust developers or a target development team may wish to + Rust community, Rust developers or a target's maintainers may wish to modify the baseline expectations of a target, or split an existing target into multiple targets with different baseline expectations. A proposal to do so will be treated similarly to the analogous promotion, demotion, or @@ -215,8 +214,8 @@ review and approval may take place in a PR adding the target to CI. suggests a block on the PR based on tests failing for the target. (A PR author must not break the build of a tier 2 target, but need not ensure the tests pass for a tier 2 target, even if notified that they fail.) -- The target development team should regularly run the testsuite for the - target, and should fix any test failures in a reasonably timely fashion. +- The target maintainers should regularly run the testsuite for the target, and + should fix any test failures in a reasonably timely fashion. - All tier 3 requirements apply. Note: some tier 2 targets additionally have binaries built to run on them as a @@ -231,16 +230,16 @@ requirements. Any proposal for demotion or removal will be CCed to people who have previously worked on the target, and will be communicated widely to the Rust community before being dropped from a stable release. -In some circumstances, especially if the target maintainer team does not -respond in a timely fashion, Rust teams may land pull requests that temporarily -disable some targets in the nightly compiler, in order to implement a feature -not yet supported by those targets. (As an example, this happened when -introducing the 128-bit types `u128` and `i128`.) Such a pull request will -include notification and coordination with the maintainers of such targets. The -maintainers of such targets will then be expected to implement the -corresponding target-specific support in order to re-enable the target. If the -maintainers of such targets cannot provide such support in time for the next -stable release, this may result in demoting or removing the targets. +In some circumstances, especially if the target maintainers do not respond in a +timely fashion, Rust teams may land pull requests that temporarily disable some +targets in the nightly compiler, in order to implement a feature not yet +supported by those targets. (As an example, this happened when introducing the +128-bit types `u128` and `i128`.) Such a pull request will include notification +and coordination with the maintainers of such targets. The maintainers of such +targets will then be expected to implement the corresponding target-specific +support in order to re-enable the target. If the maintainers of such targets +cannot provide such support in time for the next stable release, this may +result in demoting or removing the targets. ## Tier 1 target policy @@ -274,9 +273,9 @@ target, and the additional work of supporting the target. - Building the target and running the testsuite for the target must not take substantially longer than other targets. - If running the testsuite requires additional infrastructure (such as physical - systems running the target), the target development team must arrange to - provide such resources to the Rust project, to the satisfaction and approval - of the Rust infrastructure team. + systems running the target), the target maintainers must arrange to provide + such resources to the Rust project, to the satisfaction and approval of the + Rust infrastructure team. - All tier 2 requirements apply. A tier 1 target may be demoted if it no longer meets these requirements. Any From 82f711ba1189b4ff07256453f1fefc0eb9e56b77 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 03:14:22 -0700 Subject: [PATCH 054/166] Clarify "reviewers of pull requests" --- text/0000-target-tier-policy.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index d7e1dfc7901..34cf7591646 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -14,10 +14,10 @@ codifies the requirements for targets at each tier. [motivation]: #motivation 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. +reviewers of Rust 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 From 229037724ed261263a4762a5873b341a3f592520 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 03:27:19 -0700 Subject: [PATCH 055/166] Consistently use "must" for requirements --- text/0000-target-tier-policy.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 34cf7591646..a1a67855dd8 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -95,7 +95,7 @@ suitability of a target for the Rust project. If a reviewer wishes to consult a broader team for additional guidance, they may contact the compiler team. A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific -code) requires the approval of the compiler team. +code) must be reviewed and approved by the compiler team before acceptance. If the proposer of a target wishes to appeal the rejection of a target, they may contact the compiler team. @@ -144,8 +144,8 @@ At this tier, the Rust project guarantees that a target builds, and will reject patches that fail to build on a target. Thus, we place requirements that ensure the target will not block forward progress of the Rust project. -Any new tier 2 target requires compiler team approval based on these -requirements. +Any new tier 2 target must be reviewed and approved by the compiler team based +on these requirements. In addition, the infrastructure team must approve the integration of the target into Continuous Integration (CI), and the tier 2 CI-related requirements. This @@ -247,8 +247,8 @@ At this tier, the Rust project guarantees that a target builds and passes all tests, and will reject patches that fail to build or pass the testsuite on a target. We hold tier 1 targets to our highest standard of requirements. -Any new tier 1 target requires compiler team approval based on these -requirements. +Any new tier 1 target must be reviewed and approved by the compiler team based +on these requirements. In addition, the infrastructure team must approve the integration of the target into Continuous Integration (CI), and the tier 1 CI-related requirements. This From 9ef6e86478a2ce8bc5f98fdb7a2a046f4cc5964b Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 03:27:50 -0700 Subject: [PATCH 056/166] Specify use of must/should/may language All of the requirements now use must/should/may appropriately, so specify that for precision. Cite IETF RFC 2119, though here in this RFC I've intentionally kept the words in lowercase rather than all-caps. --- text/0000-target-tier-policy.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index a1a67855dd8..bf422f5b65c 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -83,6 +83,14 @@ requirements.) A target proposal is encouraged to quote the corresponding requirements verbatim as part of explaining how the target meets those requirements. +In this policy, the words "must" and "must not" specify absolute requirements +that a target must meet to qualify for a tier. The words "should" and "should +not" specify requirements that apply in almost all cases, but for which the +approving teams may be willing to grant an exception for good reason. The word +"may" indicates something entirely optional, and does not indicate guidance or +recommendations. This language is based on [IETF RFC +2119](https://tools.ietf.org/html/rfc2119). + ## Tier 3 target policy At this tier, the Rust project provides no official support for a target, so we From 288941920c8f9bdd8e532a103ab4bde26298d9cf Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 03:45:18 -0700 Subject: [PATCH 057/166] Even a tier 3 target should have target maintainers on record The level of maintenance required is much lower, but we should still have a point of contact identified. --- text/0000-target-tier-policy.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index bf422f5b65c..24e6f75d5ce 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -108,6 +108,9 @@ code) must be reviewed and approved by the compiler team before acceptance. If the proposer of a target wishes to appeal the rejection of a target, they may contact the compiler team. +- Any new tier 3 target must have a designated developer or developers (the + "target maintainers") on record to be CCed when issues arise regarding the + target. - Tier 3 targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same @@ -141,10 +144,12 @@ may contact the compiler team. target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target. -If a tier 3 target shows no signs of activity and has not built for some time, -and removing it would improve the quality of the Rust codebase, we may post a -PR to remove it; any such PR will be CCed to people who have previously worked -on the target, to check potential interest. +If a tier 3 target stops meeting these requirements, or the target maintainers +no longer have interest or time, or the target shows no signs of activity and +has not built for some time, or removing the target would improve the quality +of the Rust codebase, we may post a PR to remove it; any such PR will be CCed +to the target maintainers (and potentially other people who have previously +worked on the target), to check potential interest in improving the situation. ## Tier 2 target policy From dcb63448b54707dabbe55b34d11847ab6be52346 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 03:56:28 -0700 Subject: [PATCH 058/166] Require a compiler-team reviewer for tier 3, not just any reviewer --- text/0000-target-tier-policy.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 24e6f75d5ce..dfcfb9a2a1b 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -72,7 +72,10 @@ policy. (Such requirements may subsequently motivate additions of this policy.) While these criteria attempt to document the policy, that policy still involves human judgment. Targets must fulfill the spirit of the requirements as well, as -determined by the judgment of the approving teams. +determined by the judgment of the approving teams. Reviewers and team members +evaluating targets and target-specific patches should always use their own best +judgment regarding the quality of work, and the suitability of a target for the +Rust project. Before filing an issue or pull request (PR) to introduce or promote a target, the target should already meet the corresponding tier requirements. (This does @@ -96,14 +99,13 @@ recommendations. This language is based on [IETF RFC At this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets. -No central decision is required to add a new tier 3 target. Reviewers may -always use their own best judgment regarding the quality of work, and the -suitability of a target for the Rust project. +A proposed new tier 3 target must be reviewed and approved by a member of the +compiler team based on these requirements. The reviewer may choose to gauge +broader compiler team consensus via the "Major Change Process" (MCP). -If a reviewer wishes to consult a broader team for additional guidance, they -may contact the compiler team. A proposed target or target-specific patch that -substantially changes code shared with other targets (not just target-specific -code) must be reviewed and approved by the compiler team before acceptance. +A proposed target or target-specific patch that substantially changes code +shared with other targets (not just target-specific code) must be reviewed and +approved by the appropriate team for that shared code before acceptance. If the proposer of a target wishes to appeal the rejection of a target, they may contact the compiler team. From 5fc80f825d84fbfe3d3597c46fe40f087671cc48 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 03:57:17 -0700 Subject: [PATCH 059/166] Drop mention of appeals --- text/0000-target-tier-policy.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index dfcfb9a2a1b..fa6b7c7e29f 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -107,9 +107,6 @@ A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. -If the proposer of a target wishes to appeal the rejection of a target, they -may contact the compiler team. - - Any new tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. From d6458f657039a8a5d85c18c05d1eb270a3e52996 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 04:02:57 -0700 Subject: [PATCH 060/166] Fix expansion of MCP, and reference it in tier 2 as well --- text/0000-target-tier-policy.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index fa6b7c7e29f..4adf0bdaea5 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -101,7 +101,7 @@ place minimal requirements on the introduction of targets. A proposed new tier 3 target must be reviewed and approved by a member of the compiler team based on these requirements. The reviewer may choose to gauge -broader compiler team consensus via the "Major Change Process" (MCP). +broader compiler team consensus via a Major Change Proposal (MCP). A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and @@ -156,8 +156,9 @@ At this tier, the Rust project guarantees that a target builds, and will reject patches that fail to build on a target. Thus, we place requirements that ensure the target will not block forward progress of the Rust project. -Any new tier 2 target must be reviewed and approved by the compiler team based -on these requirements. +A proposed new tier 2 target must be reviewed and approved by the compiler team +based on these requirements. Such review and approval may occur via a Major +Change Proposal (MCP). In addition, the infrastructure team must approve the integration of the target into Continuous Integration (CI), and the tier 2 CI-related requirements. This From 5b4393bf43dab6750e958a071511fec42d0b9047 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 04:09:10 -0700 Subject: [PATCH 061/166] Suggest a full RFC for tier 1 target proposals This RFC does not require any specific approache for handling approval or consensus, but it provides guidance. For tier 1, suggest the use of a full joint RFC. --- text/0000-target-tier-policy.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 4adf0bdaea5..9d79949ddaa 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -260,15 +260,17 @@ At this tier, the Rust project guarantees that a target builds and passes all tests, and will reject patches that fail to build or pass the testsuite on a target. We hold tier 1 targets to our highest standard of requirements. -Any new tier 1 target must be reviewed and approved by the compiler team based -on these requirements. +A proposed new tier 1 target must be reviewed and approved by the compiler team +based on these requirements. In addition, the release team must approve the +long-term viability of the target, and the additional work of supporting the +target. For a tier 1 target, this will typically take place via a full RFC +proposing the target, to be jointly reviewed and approved by the compiler team +and release team. In addition, the infrastructure team must approve the integration of the target into Continuous Integration (CI), and the tier 1 CI-related requirements. This -review and approval may take place in a PR adding the target to CI. - -In addition, the release team must approve the long-term viability of the -target, and the additional work of supporting the target. +review and approval may take place in a PR adding the target to CI, or by +including the infrastructure team in the RFC proposing the target. - Tier 1 targets must have substantial, widespread interest within the developer community, and must serve the ongoing needs of multiple production From da1d1cf90822711b34acc6e50e3a11a2459d0a87 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 04:22:58 -0700 Subject: [PATCH 062/166] Allow for infra reporting consensus via a team member --- text/0000-target-tier-policy.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 9d79949ddaa..46ed3c01fa5 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -162,7 +162,8 @@ Change Proposal (MCP). In addition, the infrastructure team must approve the integration of the target into Continuous Integration (CI), and the tier 2 CI-related requirements. This -review and approval may take place in a PR adding the target to CI. +review and approval may take place in a PR adding the target to CI, or simply +by an infrastructure team member reporting the outcome of a team discussion. - A tier 2 target must have value to people other than its maintainers. - Any new tier 2 target must have a designated team of developers (the "target @@ -269,7 +270,8 @@ and release team. In addition, the infrastructure team must approve the integration of the target into Continuous Integration (CI), and the tier 1 CI-related requirements. This -review and approval may take place in a PR adding the target to CI, or by +review and approval may take place in a PR adding the target to CI, by an +infrastructure team member reporting the outcome of a team discussion, or by including the infrastructure team in the RFC proposing the target. - Tier 1 targets must have substantial, widespread interest within the From 3b6015c28d439301ba327284178511bb579218dc Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 18:16:28 -0700 Subject: [PATCH 063/166] Simplify some approval-related language --- text/0000-target-tier-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 46ed3c01fa5..f0000c81f5a 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -89,8 +89,8 @@ requirements. In this policy, the words "must" and "must not" specify absolute requirements that a target must meet to qualify for a tier. The words "should" and "should not" specify requirements that apply in almost all cases, but for which the -approving teams may be willing to grant an exception for good reason. The word -"may" indicates something entirely optional, and does not indicate guidance or +approving teams may grant an exception for good reason. The word "may" +indicates something entirely optional, and does not indicate guidance or recommendations. This language is based on [IETF RFC 2119](https://tools.ietf.org/html/rfc2119). From 5ed4ebc11c3d2f5ddf6b38c9265c044843301a62 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 18:18:38 -0700 Subject: [PATCH 064/166] Clarify what "as much of the standard library as possible" means Targets without an OS are not expected to implement `std`, for instance. --- text/0000-target-tier-policy.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index f0000c81f5a..3550be7fedd 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -118,8 +118,10 @@ approved by the appropriate team for that shared code before acceptance. - Tier 3 targets may have unusual requirements to build or use, but must not create legal issues for the Rust project or for developers who work on those targets. -- Tier 3 targets should attempt to implement as much of the standard library as - possible, but may leave some code `unimplemented!()`, whether because the +- Tier 3 targets should attempt to implement as much of the standard libraries as + possible and appropriate (`core` for most targets, `alloc` for any target + with a standard memory allocator, `std` for targets with an operating + system), but may leave some code `unimplemented!()`, whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those From d73268475cbd70aaf2346373baaf99f4cf3e2c5d Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 18:38:13 -0700 Subject: [PATCH 065/166] C calling convention --- text/0000-target-tier-policy.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 3550be7fedd..b72405f62ca 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -211,6 +211,10 @@ by an infrastructure team member reporting the outcome of a team discussion. - Tier 2 targets must not leave any significant portions of `core` or the standard library `unimplemented!()`, unless they cannot possibly be supported on the target. +- If the target supports C code, the new Rust target should support the C + calling convention for the platform via `extern "C"`. The C calling + convention does not need to be the default Rust calling convention for the + target, however. - The target must build reliably in CI. - The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional "hello world" program, or equivalent From 1ff321ebce99de7ba18b74408389f85f0fa2af90 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 18:49:37 -0700 Subject: [PATCH 066/166] Add legal and licensing requirements --- text/0000-target-tier-policy.md | 39 +++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index b72405f62ca..3ac538b73fb 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -118,6 +118,29 @@ approved by the appropriate team for that shared code before acceptance. - Tier 3 targets may have unusual requirements to build or use, but must not create legal issues for the Rust project or for developers who work on those targets. + - The target must not introduce license incompatibilities. + - Anything added to the Rust repository must be under the standard Rust + license (`MIT OR Apache-2.0`). + - The target must not cause the Rust tools or libraries built for any other + host (even when supporting cross-compilation to the new target) to depend + on any new dependency less permissive than the Rust licensing policy. This + applies whether the dependency is a Rust crate that would require adding + new license exceptions (as specified by `src/tools/tidy/src/deps.rs` in the + rust-lang/rust repository), or whether the dependency is a native library + or binary. In other words, the introduction of the target must not cause a + user installing or running a version of Rust or the Rust tools to be + subject to any new license requirements. + - If the target supports building host tools (such as `rustc` or `cargo`), + those host tools must not depend on proprietary (non-FOSS) libraries, other + than ordinary runtime libraries supplied by the platform and commonly used + by other binaries built for the target. For instance, `rustc` built for the + target may depend on a common proprietary C runtime library or console + output library, but must not depend on a proprietary code generation + library or code optimization library. Rust's license permits such + combinations, but the Rust project has no interest in maintaining such + combinations within the scope of Rust itself, even at tier 3. + - New targets should not require proprietary (non-FOSS) components to link a + functional binary or library. - Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (`core` for most targets, `alloc` for any target with a standard memory allocator, `std` for targets with an operating @@ -228,6 +251,22 @@ by an infrastructure team member reporting the outcome of a team discussion. - Tier 2 targets must support building on the existing CI infrastructure. In particular, new tier 2 targets must support cross-compiling, and must not require using the target as the host for builds. +- In addition to the legal requirements for all targets (specified in the tier + 3 requirements), because a tier 2 target typically involves the Rust project + building and supplying various compiled binaries, incorporating the target + and redistributing any resulting compiled binaries (e.g. built libraries, + host tools if any) must not impose any onerous license requirements on any + members of the Rust project, including infrastructure team members and those + operating CI systems. This is a subjective requirement, to be evaluated by + the approving teams. + - As an exception to this, if the target's primary purpose is to build + components for a Free and Open Source Software (FOSS) project licensed + under "copyleft" terms (terms which require licensing other code under the + compatible FOSS terms), such as kernel modules or plugins, then the + standard libraries for the target may potentially be subject to copyleft + terms, as long as such terms are satisfied by Rust's existing practices of + providing of full corresponding source code. Note that anything added to + the Rust repository itself must still use Rust's standard license terms. - Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. In particular, do not post comments (automated or manual) on a PR that From 4e5acef95ec6e07e5f61cb295dcf48bdb7b8c29b Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 12 Jul 2020 23:16:40 -0700 Subject: [PATCH 067/166] Reword summary of tiers for clarity --- text/0000-target-tier-policy.md | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 3ac538b73fb..96f622f29b7 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -35,11 +35,13 @@ not be the canonical home of the up-to-date target tier policy. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation -At a high level, the three tiers break down as follows: +Rust provides three tiers of target support: -- Tier 3 targets provide no guarantees of support. -- Tier 2 targets will always build, but may not pass tests. -- Tier 1 targets will always build and pass tests. +- Rust provides no guarantees about tier 3 targets. +- Rust's continuous integration checks that tier 2 targets will always build, + but they may not pass tests. +- Rust's continuous integration checks that tier 1 targets will always build + and pass tests. Adding a new tier 3 target imposes minimal requirements; we focus primarily on avoiding disruption to other ongoing Rust development. @@ -52,10 +54,13 @@ to ongoing Rust development. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation -Rust targets fall into three "tiers" of support: -- Tier 3 targets, which provide no guarantees of support. -- Tier 2 targets, which will always build but not pass tests. -- Tier 1 targets, which will always build and pass tests. +Rust provides three tiers of target support: + +- Rust provides no guarantees about tier 3 targets. +- Rust's continuous integration checks that tier 2 targets will always build, + but they may not pass tests. +- Rust's continuous integration checks that tier 1 targets will always build + and pass tests. This policy defines the requirements for accepting a proposed target at a given level of support. From 751f39674e9e57ab124d4740b0f6c78bae40c989 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Fri, 17 Jul 2020 14:17:34 -0700 Subject: [PATCH 068/166] A target should spend a reasonable amount of time at each tier --- text/0000-target-tier-policy.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 96f622f29b7..596199a9407 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -91,6 +91,15 @@ requirements.) A target proposal is encouraged to quote the corresponding requirements verbatim as part of explaining how the target meets those requirements. +Note that a target must have already received approval for the next lower tier, +and spent a reasonable amount of time at that tier, before making a proposal +for promotion to the next higher tier. This policy leaves the precise +interpretation of "reasonable amount of time" up to the approving teams; those +teams may scale the amount of time required based on their confidence in the +target and its demonstrated track record at its current tier. At a minimum, a +target should normally go through multiple stable releases of Rust before +seeking promotion to the next tier. + In this policy, the words "must" and "must not" specify absolute requirements that a target must meet to qualify for a tier. The words "should" and "should not" specify requirements that apply in almost all cases, but for which the From 027542f5067330caddc4837c7150072800ea74a1 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Fri, 17 Jul 2020 15:00:30 -0700 Subject: [PATCH 069/166] Rephrase guidance on a reasonable amount of time --- text/0000-target-tier-policy.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 596199a9407..bb8191a14a0 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -96,9 +96,8 @@ and spent a reasonable amount of time at that tier, before making a proposal for promotion to the next higher tier. This policy leaves the precise interpretation of "reasonable amount of time" up to the approving teams; those teams may scale the amount of time required based on their confidence in the -target and its demonstrated track record at its current tier. At a minimum, a -target should normally go through multiple stable releases of Rust before -seeking promotion to the next tier. +target and its demonstrated track record at its current tier. At a minimum, +multiple stable releases of Rust should occur between promotions of a target. In this policy, the words "must" and "must not" specify absolute requirements that a target must meet to qualify for a tier. The words "should" and "should From 21347b0c3e5ced96fdcf63b1f601cc83f12160dd Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Fri, 17 Jul 2020 16:45:10 -0700 Subject: [PATCH 070/166] Clarify tier 2 requirement: niche targets are fine --- text/0000-target-tier-policy.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index bb8191a14a0..ac05619b1cf 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -203,7 +203,9 @@ into Continuous Integration (CI), and the tier 2 CI-related requirements. This review and approval may take place in a PR adding the target to CI, or simply by an infrastructure team member reporting the outcome of a team discussion. -- A tier 2 target must have value to people other than its maintainers. +- A tier 2 target must have value to people other than its maintainers. (It may + still be a niche target, but it must not be exclusively useful for an + inherently closed group.) - Any new tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation From 07c4f35982fd83ef27be30c585ebdfc437fb87b3 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 29 Sep 2020 14:46:51 -0700 Subject: [PATCH 071/166] Document requirements for providing ways to run the target --- text/0000-target-tier-policy.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index ac05619b1cf..397556258fa 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -221,8 +221,11 @@ by an infrastructure team member reporting the outcome of a team discussion. every tier 2 target. - The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run - tests for the target, using emulation if possible or dedicated hardware if - necessary. + tests for the target. If at all possible, this documentation should show how + to run Rust programs and tests for the target using emulation, to allow + anyone to do so. If the target cannot be feasibly emulated, the documentation + should explain how to obtain and work with physical hardware, cloud systems, + or equivalent. - The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar. @@ -353,6 +356,16 @@ including the infrastructure team in the RFC proposing the target. systems running the target), the target maintainers must arrange to provide such resources to the Rust project, to the satisfaction and approval of the Rust infrastructure team. + - Such resources may be provided via cloud systems, via emulation, or via + physical hardware. + - If it is not possible to run the target via emulation, these resources must + additionally be sufficient for the Rust infrastructure team to make them + available for access by Rust team members, for the purposes of development + and testing. (Note that the responsibility for doing target-specific + development to keep the target well maintained remains with the target + maintainers. This requirement ensures that it is possible for other + Rust developers to test the target, but does not obligate other Rust + developers to make target-specific fixes.) - All tier 2 requirements apply. A tier 1 target may be demoted if it no longer meets these requirements. Any From 4572c26fa1437540e621ee13e605192a802ff387 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 29 Sep 2020 14:47:21 -0700 Subject: [PATCH 072/166] Document requirement to not have safety-related deficiencies Inspired by issues regarding whether a new target must support stack probes. --- text/0000-target-tier-policy.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 397556258fa..dfcdc795b4f 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -252,6 +252,15 @@ by an infrastructure team member reporting the outcome of a team discussion. - Tier 2 targets must not leave any significant portions of `core` or the standard library `unimplemented!()`, unless they cannot possibly be supported on the target. +- The code generation backend for the target should not have deficiencies that + invalidate Rust safety properties, as evaluated by the Rust compiler team. + For example, if Rust relies on a specific code generation feature to support + a memory safety property, the code generation for the target should support + that feature. If this requirement does not hold, the target must clearly and + prominently document any such limitations, such as via a failing test in the + testsuite and/or a footnote in the target tier list, and the Rust compiler + team must be satisfied with the balance between these limitations and the + difficulty of implementing the necessary features. - If the target supports C code, the new Rust target should support the C calling convention for the platform via `extern "C"`. The C calling convention does not need to be the default Rust calling convention for the From 8eb74fa0f6fa7e09eacb750d3255c1787eaba84c Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 13 Dec 2020 22:23:14 -0800 Subject: [PATCH 073/166] Wording tweak about tier 2 targets passing tests --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index dfcdc795b4f..30b3fbfec3b 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -58,7 +58,7 @@ Rust provides three tiers of target support: - Rust provides no guarantees about tier 3 targets. - Rust's continuous integration checks that tier 2 targets will always build, - but they may not pass tests. + but they may or may not pass tests. - Rust's continuous integration checks that tier 1 targets will always build and pass tests. From f81e0fbb8d4cb94c1834c1085f7d5e8bdecb758e Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 13 Dec 2020 22:25:10 -0800 Subject: [PATCH 074/166] Update requirement about designated developers --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 30b3fbfec3b..bed22390ac5 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -122,7 +122,7 @@ approved by the appropriate team for that shared code before acceptance. - Any new tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the - target. + target. (The mechanism to track and CC such developers may evolve over time.) - Tier 3 targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same From c9c51f4741d0cc586445e9cf4a9548a269556faf Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 13 Dec 2020 22:26:38 -0800 Subject: [PATCH 075/166] Add RFC PR link --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index bed22390ac5..edbbecd5e6a 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -1,6 +1,6 @@ - Feature Name: `target_tier_policy` - Start Date: 2019-09-20 -- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000) +- RFC PR: [rust-lang/rfcs#2803](https://github.com/rust-lang/rfcs/pull/2803) - Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000) # Summary From 444b6d8e4a07856c1a0f353c747ea850ee8a1c22 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 13 Dec 2020 22:28:50 -0800 Subject: [PATCH 076/166] Add note that targets require ongoing maintenance We don't want people thinking that adding a target is a one-off effort. --- text/0000-target-tier-policy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index edbbecd5e6a..0d06a9e2183 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -47,9 +47,9 @@ Adding a new tier 3 target imposes minimal requirements; we focus primarily on avoiding disruption to other ongoing Rust development. Tier 2 and tier 1 targets place work on the Rust community as a whole, to avoid -breaking the target. Thus, these tiers require commensurate efforts from the -maintainers of the target, to demonstrate value and to minimize any disruptions -to ongoing Rust development. +breaking the target. Thus, these tiers require commensurate and ongoing efforts +from the maintainers of the target, to demonstrate value and to minimize any +disruptions to ongoing Rust development. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation From a4aa1148aaa089a213dd242225fdcb7568e871f7 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 13 Dec 2020 22:30:08 -0800 Subject: [PATCH 077/166] Grammatical improvement --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 0d06a9e2183..e1effd8c23b 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -73,7 +73,7 @@ approve the addition of any target at that tier. Those teams are responsible for reviewing and evaluating the target, based on these requirements and their own judgment. Those teams may apply additional requirements, including subjective requirements, such as to deal with issues not foreseen by this -policy. (Such requirements may subsequently motivate additions of this policy.) +policy. (Such requirements may subsequently motivate additions to this policy.) While these criteria attempt to document the policy, that policy still involves human judgment. Targets must fulfill the spirit of the requirements as well, as From 4c709629bd32369c89c0f86a5301e112bd4190ae Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 13 Dec 2020 22:32:54 -0800 Subject: [PATCH 078/166] Encourage use of consistent naming conventions The requirements already encouraged using the same names as the broader ecosystem. This change additionally encourages following other naming conventions, such as those related to target CPU features, library usage, or similar. --- text/0000-target-tier-policy.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index e1effd8c23b..1336966ba0f 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -126,8 +126,9 @@ approved by the appropriate team for that shared code before acceptance. - Tier 3 targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same - names as used elsewhere in the broader ecosystem beyond Rust (such as in - other toolchains), unless they have a very good reason to diverge. + names and naming conventions as used elsewhere in the broader ecosystem + beyond Rust (such as in other toolchains), unless they have a very good + reason to diverge. - Tier 3 targets may have unusual requirements to build or use, but must not create legal issues for the Rust project or for developers who work on those targets. From f9ac528f794830d349690dc203bbb0722f69eee6 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 13 Dec 2020 22:37:50 -0800 Subject: [PATCH 079/166] Allow tier 3 code to omit *or* stub out code, as appropriate --- text/0000-target-tier-policy.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 1336966ba0f..b62d352e969 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -158,11 +158,11 @@ approved by the appropriate team for that shared code before acceptance. - Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (`core` for most targets, `alloc` for any target with a standard memory allocator, `std` for targets with an operating - system), but may leave some code `unimplemented!()`, whether because the - target makes it impossible to implement or challenging to implement. The - authors of pull requests are not obligated to avoid calling any portions of - the standard library on the basis of a tier 3 target not implementing those - portions. + system), but may leave some code unimplemented (either unavailable or stubbed + out as appropriate), whether because the target makes it impossible to + implement or challenging to implement. The authors of pull requests are not + obligated to avoid calling any portions of the standard library on the basis + of a tier 3 target not implementing those portions. - The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must From d7a209d824a86bad1cc496dbaf5ce992760087ee Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 13 Dec 2020 22:41:36 -0800 Subject: [PATCH 080/166] Make sure the policy doesn't stifle discussions about tier 3 targets We're trying to prevent messages that make a target's de-facto tier higher, not prevent discussion about a target entirely. --- text/0000-target-tier-policy.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index b62d352e969..e9111e7e2a7 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -173,6 +173,10 @@ approved by the appropriate team for that shared code before acceptance. do not post comments (automated or manual) on a PR that suggests a block on the PR based on the target. (A PR author may choose to help with a tier 3 target, but is not required to.) + - It is acceptable to manually initiate or link to a discussion about how to + make a PR and a tier 3 target compatible, but that discussion must not be + implied to block the PR unless either the PR author or PR approver want it + to be. - Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. From 76b06847fcfc3dcd6da2413db7232709893b5085 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 13 Dec 2020 22:47:14 -0800 Subject: [PATCH 081/166] Don't specifically refer to `unimplemented!()` --- text/0000-target-tier-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index e9111e7e2a7..a4cd934f958 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -255,8 +255,8 @@ by an infrastructure team member reporting the outcome of a team discussion. corresponding to the older versions, and requiring justification for a new target at a lower tier for the older OS versions). - Tier 2 targets must not leave any significant portions of `core` or the - standard library `unimplemented!()`, unless they cannot possibly be supported - on the target. + standard library unimplemented or stubbed out, unless they cannot possibly be + supported on the target. - The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team. For example, if Rust relies on a specific code generation feature to support From 900a5b28792fb392fa5fa2856ec92bb95195cec1 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 13 Dec 2020 22:49:44 -0800 Subject: [PATCH 082/166] Grammatical tweak: remove a "the" --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index a4cd934f958..7c7df930a0f 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -293,7 +293,7 @@ by an infrastructure team member reporting the outcome of a team discussion. the approving teams. - As an exception to this, if the target's primary purpose is to build components for a Free and Open Source Software (FOSS) project licensed - under "copyleft" terms (terms which require licensing other code under the + under "copyleft" terms (terms which require licensing other code under compatible FOSS terms), such as kernel modules or plugins, then the standard libraries for the target may potentially be subject to copyleft terms, as long as such terms are satisfied by Rust's existing practices of From 1d967a76913781f78e423dc0a0e97879719d8c54 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 13 Dec 2020 23:42:07 -0800 Subject: [PATCH 083/166] Add some samples of "onerous" license terms Better to give examples of these now, before there's substantial demand for new targets, to set minimum baseline expectations for what we won't put up with. --- text/0000-target-tier-policy.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 7c7df930a0f..5b96d623493 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -291,6 +291,15 @@ by an infrastructure team member reporting the outcome of a team discussion. members of the Rust project, including infrastructure team members and those operating CI systems. This is a subjective requirement, to be evaluated by the approving teams. + - "onerous" here is an intentionally subjective term. At a minimum, "onerous" + legal/licensing terms include but are *not* limited to: non-disclosure + requirements, non-compete requirements, contributor license agreements + (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, + requirements conditional on the employer or employment of any particular + Rust developers, revocable terms, any requirements that create liability + for the Rust project or its developers or users, or any requirements that + adversely affect the livelihood or prospects of the Rust project or its + developers or users. - As an exception to this, if the target's primary purpose is to build components for a Free and Open Source Software (FOSS) project licensed under "copyleft" terms (terms which require licensing other code under From 837a787e230c9894b6c7777c0640ca4a27e58881 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 00:09:30 -0800 Subject: [PATCH 084/166] Add note about future legal review processes --- text/0000-target-tier-policy.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 5b96d623493..35bc2ed1ffb 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -468,3 +468,6 @@ constitute a commitment to do so in a timely fashion. Future enhancements to the target tier policy may introduce more detailed requirements for supplying host tools for a target, or for supplying part or all of the standard library. + +In the future, we may have a specified approval body for evaluating legal +requirements, in consultation with legal professionals. From bb708a0da6d82db0d605ae109f3e9a0d204027e2 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 00:19:41 -0800 Subject: [PATCH 085/166] Update some git branch names --- text/0000-target-tier-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 35bc2ed1ffb..54fa43d58b3 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -431,7 +431,7 @@ criteria](https://ftp-master.debian.org/archive-criteria.html). Other precedents for tiered target support include [Firefox's supported build targets](https://firefox-source-docs.mozilla.org/build/buildsystem/supported-configurations.html), [node.js supported -platforms](https://github.com/nodejs/node/blob/master/BUILDING.md#supported-platforms), +platforms](https://github.com/nodejs/node/blob/HEAD/BUILDING.md#supported-platforms), and [GHC's platform support](https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms). @@ -449,7 +449,7 @@ support](https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms). - We could add them as a "marker team" (e.g. `target-xyz`) in the [rust-lang/team](https://github.com/rust-lang/team) repository. For example, see [the icebreakers-llvm - team](https://github.com/rust-lang/team/blob/master/teams/icebreakers-llvm.toml). + team](https://github.com/rust-lang/team/blob/HEAD/teams/icebreakers-llvm.toml). This would allow pinging them with `@rustbot ping target-xyz`. - We could additionally teach rustbot to automatically ping a target team when an issue is labeled with a target-specific label. From 989776eea5c5df4fb086b42f37fb42f6c6a5ac68 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 00:22:24 -0800 Subject: [PATCH 086/166] Link to Debian archive criteria source --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 54fa43d58b3..ada57d0dc92 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -426,7 +426,7 @@ Support page](https://forge.rust-lang.org/release/platform-support.html). Future expansions of such policy may find requirements from other communities useful as examples, such as Debian's [arch policy](https://release.debian.org/bullseye/arch_policy.html) and [archive -criteria](https://ftp-master.debian.org/archive-criteria.html). +criteria](https://salsa.debian.org/ftp-team/website/-/blob/HEAD/archive-criteria.html). Other precedents for tiered target support include [Firefox's supported build targets](https://firefox-source-docs.mozilla.org/build/buildsystem/supported-configurations.html), From e9154cc84ceca3ce6ae83aae38f94ce552e2e53f Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 00:55:36 -0800 Subject: [PATCH 087/166] Substantial expansion to cover host tools separately Introduce new sections for "tier 2 with host tools" and "tier 1 with host tools". --- text/0000-target-tier-policy.md | 155 +++++++++++++++++++++++++++++--- 1 file changed, 143 insertions(+), 12 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index ada57d0dc92..932f5210d84 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -66,7 +66,10 @@ This policy defines the requirements for accepting a proposed target at a given level of support. Each tier builds on all the requirements from the previous tier, unless -overridden by a stronger requirement. +overridden by a stronger requirement. Tier 2 and tier 1 also provide additional +requirements to be met if supplying host tools for the target; a target at tier +2 or tier 1 is not required to supply host tools, but if it does, it must meet +the corresponding additional requirements. The policy for each tier also documents the Rust governance teams that must approve the addition of any target at that tier. Those teams are responsible @@ -318,13 +321,6 @@ by an infrastructure team member reporting the outcome of a team discussion. should fix any test failures in a reasonably timely fashion. - All tier 3 requirements apply. -Note: some tier 2 targets additionally have binaries built to run on them as a -host (such as `rustc` and `cargo`). Such a target must meet all the -requirements above, and must additionally get the compiler and infrastructure -team to approve the building of host tools. Depending on the target and its -capabilities, this may include only `rustc` and `cargo`, or may include -additional tools such as `clippy` and `rustfmt`. - A tier 2 target may be demoted or removed if it no longer meets these requirements. Any proposal for demotion or removal will be CCed to people who have previously worked on the target, and will be communicated widely to the @@ -341,6 +337,82 @@ support in order to re-enable the target. If the maintainers of such targets cannot provide such support in time for the next stable release, this may result in demoting or removing the targets. +### Tier 2 with host tools + +Some tier 2 targets may additionally have binaries built to run on them as a +host (such as `rustc` and `cargo`). + +A proposed new tier 2 target with host tools must be reviewed and approved by +the compiler team based on these requirements. Such review and approval may +occur via a Major Change Proposal (MCP). + +In addition, the infrastructure team must approve the integration of the +target's host tools into Continuous Integration (CI), and the CI-related +requirements for host tools. This review and approval may take place in a PR +adding the target's host tools to CI, or simply by an infrastructure team +member reporting the outcome of a team discussion. + +- Tier 2 targets with host tools must additionally get the compiler and + infrastructure team to approve the building of host tools. + - Depending on the target, its capabilities, its performance, and the + likelihood of use for any given tool, this may include only `rustc` and + `cargo`, or may include additional tools such as `clippy` and `rustfmt`. + - Such approval will take into account the additional time required to build + the host tools, and the substantial additional storage required for the + host tools. +- The host tools must have direct value to people other than the target's + maintainers. (It may still be a niche target, but the host tools must not be + exclusively useful for an inherently closed group.) This requirement will be + evaluated independently from the corresponding tier 2 requirement. + - The requirement to provide "direct value" means that it does not suffice to + argue that having host tools will help the target's maintainers more easily + provide the target to others. The tools themselves must provide value to + others. +- There must be a reasonable expectation that the host tools will be used, for + purposes other than to prove that they can be used. +- The host tools must build and run reliably in CI, though they may or may not + pass tests. +- Building host tools for the target must not take substantially longer than + building host tools for other targets. +- The host tools must provide a substantively similar experience as on other + targets, subject to reasonable target limitations. + - Adding a substantively different interface to an existing tool, or a + target-specific interface to the functionality of an existing tool, + requires design and implementation approval (e.g. RFC/MCP) from the + appropriate approving teams for that tool. + - Such an interface should have a design that could potentially work for + other targets with similar properties. + - This should happen separately from the review and approval of the target, + to simplify the target review and approval processes, and to simplify the + review and approval processes for the proposed new interface. + - By way of example, a target that runs within a sandbox may need to modify + the handling of files, tool invocation, and similar to meet the + expectations and conventions of the sandbox, but must not introduce a + separate "sandboxed compilation" interface separate from the CLI interface + without going through the normal approval process for such an interface. + Such an interface should take into account potential other targets with + similar sandboxes. +- If the host tools for the platform would normally be expected to be signed or + equivalent (e.g. if running unsigned binaries or similar involves a + "developer mode" or an additional prompt), it must be possible for the Rust + project's automated builds to apply the appropriate signature process, + without any manual intervention by either Rust developers, target + maintainers, or a third party. This process must meet the approval of the + infrastructure team. + - This process may require one-time or semi-regular manual steps by the + infrastructure team, such as registration or renewal of a signing key. Any + such manual process must meet the approval of the infrastructure team. + - This requirement exists to ensure that Rust builds, including nightly + builds, can meet the necessary requirements to allow users to smoothly run + the host tools. +- Providing host tools does not exempt a target from requirements to support + cross-compilation if at all possible. +- A target may be promoted directly from tier 3 to tier 2 with host tools if it + meets all the necessary requirements, but doing so may introduce substantial + additional complexity. If in doubt, the target should qualify for tier 2 + without host tools first. +- All tier 2 requirements apply. + ## Tier 1 target policy At this tier, the Rust project guarantees that a target builds and passes all @@ -397,6 +469,69 @@ community, both when initially proposed and before being dropped from a stable release. A tier 1 target is highly unlikely to be directly removed without first being demoted to tier 2 or tier 3. +### Tier 1 with host tools + +Some tier 1 targets may additionally have binaries built to run on them as a +host (such as `rustc` and `cargo`). + +A proposed new tier 1 target with host tools must be reviewed and approved by +the compiler team based on these requirements. In addition, the release team +must approve the long-term viability of host tools for the target, and the +additional work of supporting host tools on the target. For a tier 1 target, +this will typically take place via a full RFC proposing the target, to be +jointly reviewed and approved by the compiler team and release team. + +In addition, the infrastructure team must approve the integration of the +target's host tools into Continuous Integration (CI), and the CI-related +requirements for host tools. This review and approval may take place in a PR +adding the target's host tools to CI, by an infrastructure team member +reporting the outcome of a team discussion, or by including the infrastructure +team in the RFC proposing the target. + +- Tier 1 targets with host tools must additionally get the compiler and + infrastructure team to approve the building of host tools. + - This should typically include all of the additional tools such as `clippy` + and `rustfmt`, unless there is a specific reason why a tool cannot possibly + make sense for the target. + - Unlike with tier 2, for tier 1 we will not exclude specific tools on the + sole basis of them being less likely to be used; rather, we'll take that + into account when considering whether the target should be at tier 1 with + host tools. In general, on any tier 1 target with host tools, people + should be able to expect to find and install all the same components that + they would for any other tier 1 target with host tools. + - Such approval will take into account the additional time required to build + the host tools, and the substantial additional storage required for the + host tools. +- Host tools for the target must have substantial, widespread interest within + the developer community, and must serve the ongoing needs of multiple + production users of Rust across multiple organizations or projects. These + requirements are subjective, and determined by consensus of the approving + teams. This requirement will be evaluated independently from the + corresponding tier 1 requirement; it is possible for a target to have + sufficient interest for cross-compilation, but not have sufficient interest + for native compilation. The host tools may be dropped if they no longer meet + this requirement, even if the target otherwise qualifies as tier 1. +- The host tools must build, run, and pass tests reliably in CI. + - The target must not disable an excessive number of tests or pieces of tests + in the testsuite in order to do so. This is a subjective requirement. +- New tier 1 targets with host tools must not have a hard requirement for + signed, verified, or otherwise "approved" binaries. Developers must be able + to build, run, and test binaries for the target on systems they control. + (Doing so may require enabling some appropriate "developer mode" on such + systems, but must not require the payment of any additional fee or other + consideration, or agreement to any onerous legal agreements.) + - While the Rust project may supply appropriately signed tools, this + requirement exists to ensure that Rust developers can help develop and test + Rust for the target, and that development or testing for the target is not + limited to an exclusive group or entity. +- Providing host tools does not exempt a target from requirements to support + cross-compilation if at all possible. +- A target seeking promotion to tier 1 with host tools should typically either + be tier 2 with host tools or tier 1 without host tools, to reduce the number + of requirements to simultaneously review and approve. +- All requirements for tier 2 targets with host tools apply. +- All tier 1 requirements apply. + # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives @@ -465,9 +600,5 @@ Some of our existing targets may not meet all of these criteria today. We may wish to audit existing targets against these criteria, but this RFC does not constitute a commitment to do so in a timely fashion. -Future enhancements to the target tier policy may introduce more detailed -requirements for supplying host tools for a target, or for supplying part or -all of the standard library. - In the future, we may have a specified approval body for evaluating legal requirements, in consultation with legal professionals. From 90f1b791a7a2ed3027ac977e726bc0df8ba66a00 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 01:01:34 -0800 Subject: [PATCH 088/166] Separate out host tool transition steps from requirements --- text/0000-target-tier-policy.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 932f5210d84..98a9a823f6e 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -407,12 +407,13 @@ member reporting the outcome of a team discussion. the host tools. - Providing host tools does not exempt a target from requirements to support cross-compilation if at all possible. -- A target may be promoted directly from tier 3 to tier 2 with host tools if it - meets all the necessary requirements, but doing so may introduce substantial - additional complexity. If in doubt, the target should qualify for tier 2 - without host tools first. - All tier 2 requirements apply. +A target may be promoted directly from tier 3 to tier 2 with host tools if it +meets all the necessary requirements, but doing so may introduce substantial +additional complexity. If in doubt, the target should qualify for tier 2 +without host tools first. + ## Tier 1 target policy At this tier, the Rust project guarantees that a target builds and passes all @@ -526,12 +527,13 @@ team in the RFC proposing the target. limited to an exclusive group or entity. - Providing host tools does not exempt a target from requirements to support cross-compilation if at all possible. -- A target seeking promotion to tier 1 with host tools should typically either - be tier 2 with host tools or tier 1 without host tools, to reduce the number - of requirements to simultaneously review and approve. - All requirements for tier 2 targets with host tools apply. - All tier 1 requirements apply. +A target seeking promotion to tier 1 with host tools should typically either be +tier 2 with host tools or tier 1 without host tools, to reduce the number of +requirements to simultaneously review and approve. + # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives From df1264768a5aa8505af57bda3407a6b6c41ef28e Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 01:04:17 -0800 Subject: [PATCH 089/166] Clarify a legal requirement --- text/0000-target-tier-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 98a9a823f6e..77a509a9864 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -133,8 +133,8 @@ approved by the appropriate team for that shared code before acceptance. beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. - Tier 3 targets may have unusual requirements to build or use, but must not - create legal issues for the Rust project or for developers who work on those - targets. + create legal issues or impose onerous legal terms for the Rust project or for + Rust developers or users. - The target must not introduce license incompatibilities. - Anything added to the Rust repository must be under the standard Rust license (`MIT OR Apache-2.0`). From a0da271ff254acc1cfb356b44d5c158c4afce9cf Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 01:08:35 -0800 Subject: [PATCH 090/166] Modify requirement for cross-compilation support In practice, this is a strong "should", not a hard "must". --- text/0000-target-tier-policy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 77a509a9864..e430902692f 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -283,9 +283,9 @@ by an infrastructure team member reporting the outcome of a team discussion. slowest target in CI. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target into account. -- Tier 2 targets must support building on the existing CI infrastructure. In - particular, new tier 2 targets must support cross-compiling, and must not - require using the target as the host for builds. +- New tier 2 targets should, if at all possible, support cross-compiling. New + tier 2 targets should not require using the target as the host for builds, + even if the target supports host tools. - In addition to the legal requirements for all targets (specified in the tier 3 requirements), because a tier 2 target typically involves the Rust project building and supplying various compiled binaries, incorporating the target From c4301356829bc39be40598086dfcaed5ab7d2484 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 01:13:32 -0800 Subject: [PATCH 091/166] Avoid redundantly restating approving teams within host tools requirements --- text/0000-target-tier-policy.md | 41 +++++++++++++++------------------ 1 file changed, 19 insertions(+), 22 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index e430902692f..707a2f32ebf 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -352,14 +352,13 @@ requirements for host tools. This review and approval may take place in a PR adding the target's host tools to CI, or simply by an infrastructure team member reporting the outcome of a team discussion. -- Tier 2 targets with host tools must additionally get the compiler and - infrastructure team to approve the building of host tools. - - Depending on the target, its capabilities, its performance, and the - likelihood of use for any given tool, this may include only `rustc` and - `cargo`, or may include additional tools such as `clippy` and `rustfmt`. - - Such approval will take into account the additional time required to build - the host tools, and the substantial additional storage required for the - host tools. +- Depending on the target, its capabilities, its performance, and the + likelihood of use for any given tool, the host tools provided for a tier 2 + target may include only `rustc` and `cargo`, or may include additional tools + such as `clippy` and `rustfmt`. +- Approval of host tools will take into account the additional time required to + build the host tools, and the substantial additional storage required for the + host tools. - The host tools must have direct value to people other than the target's maintainers. (It may still be a niche target, but the host tools must not be exclusively useful for an inherently closed group.) This requirement will be @@ -489,20 +488,18 @@ adding the target's host tools to CI, by an infrastructure team member reporting the outcome of a team discussion, or by including the infrastructure team in the RFC proposing the target. -- Tier 1 targets with host tools must additionally get the compiler and - infrastructure team to approve the building of host tools. - - This should typically include all of the additional tools such as `clippy` - and `rustfmt`, unless there is a specific reason why a tool cannot possibly - make sense for the target. - - Unlike with tier 2, for tier 1 we will not exclude specific tools on the - sole basis of them being less likely to be used; rather, we'll take that - into account when considering whether the target should be at tier 1 with - host tools. In general, on any tier 1 target with host tools, people - should be able to expect to find and install all the same components that - they would for any other tier 1 target with host tools. - - Such approval will take into account the additional time required to build - the host tools, and the substantial additional storage required for the - host tools. +- Tier 1 targets with host tools should typically include all of the additional + tools such as `clippy` and `rustfmt`, unless there is a target-specific + reason why a tool cannot possibly make sense for the target. + - Unlike with tier 2, for tier 1 we will not exclude specific tools on the + sole basis of them being less likely to be used; rather, we'll take that + into account when considering whether the target should be at tier 1 with + host tools. In general, on any tier 1 target with host tools, people + should be able to expect to find and install all the same components that + they would for any other tier 1 target with host tools. +- Approval of host tools will take into account the additional time required to + build the host tools, and the substantial additional storage required for the + host tools. - Host tools for the target must have substantial, widespread interest within the developer community, and must serve the ongoing needs of multiple production users of Rust across multiple organizations or projects. These From aaad0e4926eeb811895d18a7179caead24b0c19a Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 01:15:28 -0800 Subject: [PATCH 092/166] Wording tweak for host tools --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 707a2f32ebf..e77e97fe685 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -69,7 +69,7 @@ Each tier builds on all the requirements from the previous tier, unless overridden by a stronger requirement. Tier 2 and tier 1 also provide additional requirements to be met if supplying host tools for the target; a target at tier 2 or tier 1 is not required to supply host tools, but if it does, it must meet -the corresponding additional requirements. +the corresponding additional requirements for host tools. The policy for each tier also documents the Rust governance teams that must approve the addition of any target at that tier. Those teams are responsible From 2e972167309a5d8d7c7385caac543e2951d80119 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 01:17:12 -0800 Subject: [PATCH 093/166] Targets and their tiers (including "with host tools") will be listed --- text/0000-target-tier-policy.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index e77e97fe685..f76f766eff4 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -94,6 +94,11 @@ requirements.) A target proposal is encouraged to quote the corresponding requirements verbatim as part of explaining how the target meets those requirements. +All supported targets and their corresponding tiers ("tier 3", "tier 2", "tier +2 with host tools", "tier 1", or "tier 1 with host tools") will be documented +on an appropriate official page, such as +. + Note that a target must have already received approval for the next lower tier, and spent a reasonable amount of time at that tier, before making a proposal for promotion to the next higher tier. This policy leaves the precise From e1be462e25d14c2025084dab09e8e8e14af93179 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 01:20:30 -0800 Subject: [PATCH 094/166] Clarification on target naming and disruption of renaming --- text/0000-target-tier-policy.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index f76f766eff4..3e223022c80 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -131,12 +131,13 @@ approved by the appropriate team for that shared code before acceptance. - Any new tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.) -- Tier 3 targets must use naming consistent with any existing targets; for - instance, a target for the same CPU or OS as an existing Rust target should - use the same name for that CPU or OS. Targets should normally use the same - names and naming conventions as used elsewhere in the broader ecosystem - beyond Rust (such as in other toolchains), unless they have a very good - reason to diverge. +- Targets must use naming consistent with any existing targets; for instance, a + target for the same CPU or OS as an existing Rust target should use the same + name for that CPU or OS. Targets should normally use the same names and + naming conventions as used elsewhere in the broader ecosystem beyond Rust + (such as in other toolchains), unless they have a very good reason to + diverge. Changing the name of a target can be highly disruptive, especially + once the target reaches a higher tier. - Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. From ddbda1bb827dccdb23f67e69e33a9baf0f131310 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 01:21:30 -0800 Subject: [PATCH 095/166] Move clarifiation of "onerous" --- text/0000-target-tier-policy.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 3e223022c80..b30794346bf 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -164,6 +164,15 @@ approved by the appropriate team for that shared code before acceptance. combinations within the scope of Rust itself, even at tier 3. - New targets should not require proprietary (non-FOSS) components to link a functional binary or library. + - "onerous" here is an intentionally subjective term. At a minimum, "onerous" + legal/licensing terms include but are *not* limited to: non-disclosure + requirements, non-compete requirements, contributor license agreements + (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, + requirements conditional on the employer or employment of any particular + Rust developers, revocable terms, any requirements that create liability + for the Rust project or its developers or users, or any requirements that + adversely affect the livelihood or prospects of the Rust project or its + developers or users. - Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (`core` for most targets, `alloc` for any target with a standard memory allocator, `std` for targets with an operating @@ -300,15 +309,6 @@ by an infrastructure team member reporting the outcome of a team discussion. members of the Rust project, including infrastructure team members and those operating CI systems. This is a subjective requirement, to be evaluated by the approving teams. - - "onerous" here is an intentionally subjective term. At a minimum, "onerous" - legal/licensing terms include but are *not* limited to: non-disclosure - requirements, non-compete requirements, contributor license agreements - (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, - requirements conditional on the employer or employment of any particular - Rust developers, revocable terms, any requirements that create liability - for the Rust project or its developers or users, or any requirements that - adversely affect the livelihood or prospects of the Rust project or its - developers or users. - As an exception to this, if the target's primary purpose is to build components for a Free and Open Source Software (FOSS) project licensed under "copyleft" terms (terms which require licensing other code under From 408614e55e2afb2dbb6ac144a327f666c4864608 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 01:22:32 -0800 Subject: [PATCH 096/166] Add sample smoke test `./x.py test --no-run` --- text/0000-target-tier-policy.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index b30794346bf..13d82c75bdd 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -290,10 +290,10 @@ by an infrastructure team member reporting the outcome of a team discussion. target, however. - The target must build reliably in CI. - The approving teams may additionally require that a subset of tests pass in - CI, such as enough to build a functional "hello world" program, or equivalent - "smoke tests". In particular, this requirement may apply if the target builds - host tools, or if the tests in question provide substantial value via early - detection of critical problems. + CI, such as enough to build a functional "hello world" program, `./x.py test + --no-run`, or equivalent "smoke tests". In particular, this requirement may + apply if the target builds host tools, or if the tests in question provide + substantial value via early detection of critical problems. - Building the target in CI must not take substantially longer than the current slowest target in CI. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target From 5247216059a42126bdc851deee6c120d90e399db Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 01:26:11 -0800 Subject: [PATCH 097/166] Mention target name ambiguity --- text/0000-target-tier-policy.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 13d82c75bdd..9d97fe2567e 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -138,6 +138,11 @@ approved by the appropriate team for that shared code before acceptance. (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier. + - Target names should not introduce undue confusion or ambiguity unless + absolutely necessary to maintain ecosystem compatibility. For example, if + the name of the target makes people extremely likely to form incorrect + beliefs about what it targets, the name should be changed or augmented to + disambiguate it. - Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users. From d78eb1e5cd9af5638f1b02a768a1def1c113195c Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 01:32:48 -0800 Subject: [PATCH 098/166] Clarify why naming is important even for a tier 3 target --- text/0000-target-tier-policy.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 9d97fe2567e..456a48dd17a 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -137,7 +137,8 @@ approved by the appropriate team for that shared code before acceptance. naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially - once the target reaches a higher tier. + once the target reaches a higher tier, so getting the name right is important + even for a tier 3 target. - Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect From d2fa76abc35872098ded32a4ad2eee5e81b06f03 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 01:36:00 -0800 Subject: [PATCH 099/166] Mention the alternative possibility of renumbering tiers --- text/0000-target-tier-policy.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 456a48dd17a..1f1818f3ef4 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -562,6 +562,14 @@ increase the resulting complexity and result in discussions in multiple places. We could introduce specific time requirements for the amount of time a target must spend at a tier before becoming eligible for promotion to a higher tier. +We could renumber tiers, rather than having "tier 2 with host tools" and "tier +1 with host tools". However, some targets may by design never reach "tier 1 +with host tools", and this would make such targets seem deficient or +second-class compared to whatever "tier 1" ended up being called. In addition, +people already widely use the existing tier 1/2/3 numbering, and anything +changing that numbering would introduce confusion; such a renumbering seems +unlikely to provide value commensurate with that confusion. + # Prior art [prior-art]: #prior-art From f3ba93b27cd39a3ac5f902976507f68e40270c33 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 04:00:11 -0800 Subject: [PATCH 100/166] Simplify summary --- text/0000-target-tier-policy.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 1f1818f3ef4..0c07f73e319 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -6,9 +6,8 @@ # Summary [summary]: #summary -We should have an official policy for adding new tier 3 targets, and for -raising targets to tier 2 (with `rustup` builds) or even tier 1. This RFC -codifies the requirements for targets at each tier. +This RFC codifies the requirements for each target tier, and for moving targets +to a different tier. # Motivation [motivation]: #motivation From 0a424a6eb736db44e24db43537a1f443f0e5b4d6 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 04:00:58 -0800 Subject: [PATCH 101/166] Clarify summary of tier 3 targets --- text/0000-target-tier-policy.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 0c07f73e319..e4864923444 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -36,7 +36,8 @@ not be the canonical home of the up-to-date target tier policy. Rust provides three tiers of target support: -- Rust provides no guarantees about tier 3 targets. +- Rust provides no guarantees about tier 3 targets; they exist in the codebase, + but may or may not build. - Rust's continuous integration checks that tier 2 targets will always build, but they may not pass tests. - Rust's continuous integration checks that tier 1 targets will always build From 897c3e2307b3e294d5639e62216a8227b75b6e78 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 04:03:35 -0800 Subject: [PATCH 102/166] Clarify promotion timing requirements --- text/0000-target-tier-policy.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index e4864923444..27d2ddb4ceb 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -101,7 +101,8 @@ on an appropriate official page, such as Note that a target must have already received approval for the next lower tier, and spent a reasonable amount of time at that tier, before making a proposal -for promotion to the next higher tier. This policy leaves the precise +for promotion to the next higher tier; this is true even if a target meets the +requirements for several tiers at once. This policy leaves the precise interpretation of "reasonable amount of time" up to the approving teams; those teams may scale the amount of time required based on their confidence in the target and its demonstrated track record at its current tier. At a minimum, From 3ceaa79df1c3d296079a4f6e8c8be189d56b2a63 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 04:07:46 -0800 Subject: [PATCH 103/166] Timing of changes that might break targets --- text/0000-target-tier-policy.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 27d2ddb4ceb..1c39304b127 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -344,11 +344,13 @@ timely fashion, Rust teams may land pull requests that temporarily disable some targets in the nightly compiler, in order to implement a feature not yet supported by those targets. (As an example, this happened when introducing the 128-bit types `u128` and `i128`.) Such a pull request will include notification -and coordination with the maintainers of such targets. The maintainers of such -targets will then be expected to implement the corresponding target-specific -support in order to re-enable the target. If the maintainers of such targets -cannot provide such support in time for the next stable release, this may -result in demoting or removing the targets. +and coordination with the maintainers of such targets, and will ideally happen +towards the beginning of a new development cycle to give maintainers time to +update their targets. The maintainers of such targets will then be expected to +implement the corresponding target-specific support in order to re-enable the +target. If the maintainers of such targets cannot provide such support in time +for the next stable release, this may result in demoting or removing the +targets. ### Tier 2 with host tools From 1d5a8fcfe28a5d5867fee6df93b9f05cb22c9dd1 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 04:12:29 -0800 Subject: [PATCH 104/166] Elaborate a bit on co-evolving targets --- text/0000-target-tier-policy.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 1c39304b127..4b27deba918 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -282,6 +282,11 @@ by an infrastructure team member reporting the outcome of a team discussion. - Tier 2 targets must not leave any significant portions of `core` or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target. + - The right approach to handling a missing feature from a target may depend + on whether the target seems likely to develop the feature in the future. In + some cases, a target may be co-developed along with Rust support, and Rust + may gain new features on the target as that target gains the capabilities + to support those features. - The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team. For example, if Rust relies on a specific code generation feature to support From f505fcd24c8a9a6b167d91ee3fe54e78a5dfabac Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 04:15:57 -0800 Subject: [PATCH 105/166] Note that cross-compiling the testsuite is OK --- text/0000-target-tier-policy.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 4b27deba918..dbd9d25cbee 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -461,6 +461,9 @@ including the infrastructure team in the RFC proposing the target. - The target must build and pass tests reliably in CI. - The target must not disable an excessive number of tests or pieces of tests in the testsuite in order to do so. This is a subjective requirement. + - If the target does not have host tools support, or if the target has low + performance, CI may cross-compile the testsuite from another platform, and + then run the compiled tests natively. - The target must provide as much of the Rust standard library as is feasible and appropriate to provide. For instance, if the target has a standard memory allocator, it must provide an implementation of `alloc` and the associated From 220ce56405e2edb8f0b8bb546aa8b82643df2664 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 04:17:38 -0800 Subject: [PATCH 106/166] Mention "development platform" and "compilation target" --- text/0000-target-tier-policy.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index dbd9d25cbee..e23737feed5 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -360,7 +360,8 @@ targets. ### Tier 2 with host tools Some tier 2 targets may additionally have binaries built to run on them as a -host (such as `rustc` and `cargo`). +host (such as `rustc` and `cargo`). This allows the target to be used as a +development platform, not just a compilation target. A proposed new tier 2 target with host tools must be reviewed and approved by the compiler team based on these requirements. Such review and approval may @@ -495,7 +496,8 @@ first being demoted to tier 2 or tier 3. ### Tier 1 with host tools Some tier 1 targets may additionally have binaries built to run on them as a -host (such as `rustc` and `cargo`). +host (such as `rustc` and `cargo`). This allows the target to be used as a +development platform, not just a compilation target. A proposed new tier 1 target with host tools must be reviewed and approved by the compiler team based on these requirements. In addition, the release team From dc652a06a55ba18c0c6a219a279eaa8b1f481e5e Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 04:20:37 -0800 Subject: [PATCH 107/166] Clarify that demotion of a tier 1 target requires a full RFC --- text/0000-target-tier-policy.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index e23737feed5..7ec7917acc4 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -488,10 +488,11 @@ including the infrastructure team in the RFC proposing the target. - All tier 2 requirements apply. A tier 1 target may be demoted if it no longer meets these requirements. Any -proposal for demotion or removal will be communicated widely to the Rust -community, both when initially proposed and before being dropped from a stable -release. A tier 1 target is highly unlikely to be directly removed without -first being demoted to tier 2 or tier 3. +proposal for demotion of a tier 1 target requires a full RFC process, with +approval by the compiler and release teams. Any such proposal will be +communicated widely to the Rust community, both when initially proposed and +before being dropped from a stable release. A tier 1 target is highly unlikely +to be directly removed without first being demoted to tier 2 or tier 3. ### Tier 1 with host tools From 14948a05f90f8257e1361ec3d318eff0e1ecc328 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 04:24:45 -0800 Subject: [PATCH 108/166] Discussion demotion of tier 1 targets with host tools --- text/0000-target-tier-policy.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 7ec7917acc4..ce3e96f9547 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -557,6 +557,15 @@ A target seeking promotion to tier 1 with host tools should typically either be tier 2 with host tools or tier 1 without host tools, to reduce the number of requirements to simultaneously review and approve. +In addition to the general process for demoting a tier 1 target, a tier 1 +target with host tools may be demoted (including having its host tools dropped, +or being demoted to tier 2 with host tools) if it no longer meets these +requirements but still meets the requirements for a lower tier. Any proposal +for demotion of a tier 1 target (with or without host tools) requires a full +RFC process, with approval by the compiler and release teams. Any such proposal +will be communicated widely to the Rust community, both when initially proposed +and before being dropped from a stable release. + # Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives From b48aa514e2711bf865e887ffb56c9404f4fa0ec6 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 04:25:28 -0800 Subject: [PATCH 109/166] Clarify that, for a demotion, a target must still meet the lower-tier requirements --- text/0000-target-tier-policy.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index ce3e96f9547..132bef0dd39 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -487,12 +487,13 @@ including the infrastructure team in the RFC proposing the target. developers to make target-specific fixes.) - All tier 2 requirements apply. -A tier 1 target may be demoted if it no longer meets these requirements. Any -proposal for demotion of a tier 1 target requires a full RFC process, with -approval by the compiler and release teams. Any such proposal will be -communicated widely to the Rust community, both when initially proposed and -before being dropped from a stable release. A tier 1 target is highly unlikely -to be directly removed without first being demoted to tier 2 or tier 3. +A tier 1 target may be demoted if it no longer meets these requirements but +still meets the requirements for a lower tier. Any proposal for demotion of a +tier 1 target requires a full RFC process, with approval by the compiler and +release teams. Any such proposal will be communicated widely to the Rust +community, both when initially proposed and before being dropped from a stable +release. A tier 1 target is highly unlikely to be directly removed without +first being demoted to tier 2 or tier 3. ### Tier 1 with host tools From a5c8469cd40aaaf68f019b92df847d4b52d809df Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 04:29:05 -0800 Subject: [PATCH 110/166] Allow tier 1 targets to raise their baseline without a full RFC --- text/0000-target-tier-policy.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 132bef0dd39..2edf39f3a0a 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -495,6 +495,10 @@ community, both when initially proposed and before being dropped from a stable release. A tier 1 target is highly unlikely to be directly removed without first being demoted to tier 2 or tier 3. +Raising the baseline expectations of a tier 1 target (such as the minimum CPU +features or OS version required) requires the approval of the compiler and +release teams, but does not necessarily require a full RFC. + ### Tier 1 with host tools Some tier 1 targets may additionally have binaries built to run on them as a From 2f7df80d8d4cdc739289d5c84831b2cf6d0d66eb Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 13:53:15 -0800 Subject: [PATCH 111/166] Add some notes to help avoid conflicts of interest Hopefully this will help anyone who might otherwise be placed in a position of being expected to approve/reject a target due to employment or other legal obligations. People in such a position may be able to point to this language to protect themselves. This language may additionally help protect Rust team members from causes of action brought by parties with a vested interest in the status of a target. (There may, in the future, be *substantial* business interests depending on the support status of specific targets.) --- text/0000-target-tier-policy.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 2edf39f3a0a..94222ce6c35 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -83,7 +83,8 @@ human judgment. Targets must fulfill the spirit of the requirements as well, as determined by the judgment of the approving teams. Reviewers and team members evaluating targets and target-specific patches should always use their own best judgment regarding the quality of work, and the suitability of a target for the -Rust project. +Rust project. Neither this policy nor any decisions made regarding targets +shall create any binding agreement or estoppel by any party. Before filing an issue or pull request (PR) to introduce or promote a target, the target should already meet the corresponding tier requirements. (This does @@ -180,6 +181,20 @@ approved by the appropriate team for that shared code before acceptance. for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users. +- Neither this policy nor any decisions made regarding targets shall create any + binding agreement or estoppel by any party. If any member of an approving + Rust team serves as one of the maintainers of a target, or has any legal or + employment requirement (explicit or implicit) that might affect their + decisions regarding a target, they must recuse themselves from any approval + process regarding the target's tier status, though they may otherwise + participate in discussions. + - This requirement does not prevent part or all of this policy from being + cited in an explicit contract or work agreement (e.g. to implement or + maintain support for a target). This requirement exists to ensure that a + developer or team responsible for reviewing and approving a target does not + face any legal threats or obligations that would prevent them from freely + exercising their judgment in such approval, even if such judgment involves + subjective matters or goes beyond the letter of these requirements. - Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (`core` for most targets, `alloc` for any target with a standard memory allocator, `std` for targets with an operating From bf3ddb6c21169668ee3fd274abccca31102817a1 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 13:56:09 -0800 Subject: [PATCH 112/166] Add expectations about emulation accuracy --- text/0000-target-tier-policy.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 94222ce6c35..4a12106e41f 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -492,6 +492,12 @@ including the infrastructure team in the RFC proposing the target. Rust infrastructure team. - Such resources may be provided via cloud systems, via emulation, or via physical hardware. + - If the target requires the use of emulation to meet any of the tier + requirements, the approving teams for those requirements must have high + confidence in the accuracy of the emulation, such that discrepancies + between emulation and native operation that affect test results will + constitute a high-priority bug in either the emulation or the + implementation of the target. - If it is not possible to run the target via emulation, these resources must additionally be sufficient for the Rust infrastructure team to make them available for access by Rust team members, for the purposes of development From 0697637483bd7251bd35920907b17ef900ece53c Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 14 Dec 2020 14:01:17 -0800 Subject: [PATCH 113/166] Add further discussion and requirements regarding performance considerations --- text/0000-target-tier-policy.md | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 4a12106e41f..9f3bed50c44 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -478,14 +478,21 @@ including the infrastructure team in the RFC proposing the target. - The target must not disable an excessive number of tests or pieces of tests in the testsuite in order to do so. This is a subjective requirement. - If the target does not have host tools support, or if the target has low - performance, CI may cross-compile the testsuite from another platform, and - then run the compiled tests natively. + performance, the infrastructure team may choose to have CI cross-compile + the testsuite from another platform, and then run the compiled tests + either natively or via accurate emulation. However, the approving teams may + take such performance considerations into account when determining the + viability of the target or of its host tools. - The target must provide as much of the Rust standard library as is feasible and appropriate to provide. For instance, if the target has a standard memory allocator, it must provide an implementation of `alloc` and the associated data structures. - Building the target and running the testsuite for the target must not take substantially longer than other targets. + - In particular, if building the target takes a reasonable amount of time, + but the target cannot run the testsuite in a timely fashion due to low + performance of either native code or accurate emulation, that alone may + prevent the target from qualifying as tier 1. - If running the testsuite requires additional infrastructure (such as physical systems running the target), the target maintainers must arrange to provide such resources to the Rust project, to the satisfaction and approval of the @@ -564,6 +571,12 @@ team in the RFC proposing the target. - The host tools must build, run, and pass tests reliably in CI. - The target must not disable an excessive number of tests or pieces of tests in the testsuite in order to do so. This is a subjective requirement. +- Building the host tools and running the testsuite for the host tools must not + take substantially longer than other targets. + - In particular, if building the target's host tools takes a reasonable + amount of time, but the target cannot run the testsuite in a timely fashion + due to low performance of either native code or accurate emulation, that + alone may prevent the target from qualifying as tier 1 with host tools. - New tier 1 targets with host tools must not have a hard requirement for signed, verified, or otherwise "approved" binaries. Developers must be able to build, run, and test binaries for the target on systems they control. From 55584098ea29258f646403606210dfd06c9eab7b Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 7 Mar 2021 16:55:50 -0800 Subject: [PATCH 114/166] Document prior art for how to track and contact target maintainers --- text/0000-target-tier-policy.md | 22 ++++------------------ 1 file changed, 4 insertions(+), 18 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 9f3bed50c44..5f644d31251 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -651,24 +651,10 @@ platforms](https://github.com/nodejs/node/blob/HEAD/BUILDING.md#supported-platfo and [GHC's platform support](https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms). -# Unresolved questions -[unresolved-questions]: #unresolved-questions - -- How should we track the maintainers of a target, so that we can page them if - we need an issue addressed involving that target? - - We could use github teams, which could be directly mentioned in an issue or - PR to get their attention. However, this would also put a "Member" badge on - the members of those teams, which may give an unwarranted appearance of - official status. - - We could track them in a document posted somewhere, and manually copy-paste - the list to ping them. - - We could add them as a "marker team" (e.g. `target-xyz`) in the - [rust-lang/team](https://github.com/rust-lang/team) repository. For - example, see [the icebreakers-llvm - team](https://github.com/rust-lang/team/blob/HEAD/teams/icebreakers-llvm.toml). - This would allow pinging them with `@rustbot ping target-xyz`. - - We could additionally teach rustbot to automatically ping a target team - when an issue is labeled with a target-specific label. +This RFC doesn't specify how to track and contact the maintainers of a target. +Some existing Rust targets use "marker teams" that support pinging via rustbot. +We could additionally teach rustbot to automatically ping a target team when an +issue is labeled with a target-specific label. # Future possibilities [future-possibilities]: #future-possibilities From c996aea56dabcfa055424b830480e7bfb1957a77 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 7 Mar 2021 16:56:10 -0800 Subject: [PATCH 115/166] Adjust language about alloc to avoid prescriptive policy about allocators The target tier policy provides policy about targets, not about allocators. Change the language about the alloc crate to avoid any specifics about how to implement alloc. --- text/0000-target-tier-policy.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 5f644d31251..e925586a343 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -195,14 +195,14 @@ approved by the appropriate team for that shared code before acceptance. face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements. -- Tier 3 targets should attempt to implement as much of the standard libraries as - possible and appropriate (`core` for most targets, `alloc` for any target - with a standard memory allocator, `std` for targets with an operating - system), but may leave some code unimplemented (either unavailable or stubbed - out as appropriate), whether because the target makes it impossible to - implement or challenging to implement. The authors of pull requests are not - obligated to avoid calling any portions of the standard library on the basis - of a tier 3 target not implementing those portions. +- Tier 3 targets should attempt to implement as much of the standard libraries + as possible and appropriate (`core` for most targets, `alloc` for targets + that can support dynamic memory allocation, `std` for targets with an + operating system), but may leave some code unimplemented (either unavailable + or stubbed out as appropriate), whether because the target makes it + impossible to implement or challenging to implement. The authors of pull + requests are not obligated to avoid calling any portions of the standard + library on the basis of a tier 3 target not implementing those portions. - The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must @@ -484,9 +484,9 @@ including the infrastructure team in the RFC proposing the target. take such performance considerations into account when determining the viability of the target or of its host tools. - The target must provide as much of the Rust standard library as is feasible - and appropriate to provide. For instance, if the target has a standard memory - allocator, it must provide an implementation of `alloc` and the associated - data structures. + and appropriate to provide. For instance, if the target can support dynamic + memory allocation, it must provide an implementation of `alloc` and the + associated data structures. - Building the target and running the testsuite for the target must not take substantially longer than other targets. - In particular, if building the target takes a reasonable amount of time, From 4509ce949c821453dd30d827a59383ebcf6f758e Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 15 Mar 2021 14:57:42 -0700 Subject: [PATCH 116/166] Clarify requirements about signing, and apply it to all tier 1 targets This requirement previously just applied to tier 1 with host tools; move it to apply to all tier 1 targets. Clarify the language in the sub-bullet. --- text/0000-target-tier-policy.md | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index e925586a343..962af80f3b7 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -513,6 +513,20 @@ including the infrastructure team in the RFC proposing the target. maintainers. This requirement ensures that it is possible for other Rust developers to test the target, but does not obligate other Rust developers to make target-specific fixes.) +- New tier 1 targets must not have a hard requirement for signed, verified, or + otherwise "approved" binaries. Developers must be able to build, run, and + test binaries for the target on systems they control. (Doing so may require + enabling some appropriate "developer mode" on such systems, but must not + require the payment of any additional fee or other consideration, or + agreement to any onerous legal agreements.) + - The Rust project may decide to supply appropriately signed binaries if + doing so provides a smoother experience for developers using the target, + and a tier 2 target with host tools already requires providing appropriate + mechanisms that enable our infrastructure to provide such signed binaries. + However, this additional tier 1 requirement ensures that Rust developers + can help develop and test Rust software for the target (including Rust + itself), and that development or testing for the target is not limited to + an exclusive group or entity. - All tier 2 requirements apply. A tier 1 target may be demoted if it no longer meets these requirements but @@ -577,16 +591,6 @@ team in the RFC proposing the target. amount of time, but the target cannot run the testsuite in a timely fashion due to low performance of either native code or accurate emulation, that alone may prevent the target from qualifying as tier 1 with host tools. -- New tier 1 targets with host tools must not have a hard requirement for - signed, verified, or otherwise "approved" binaries. Developers must be able - to build, run, and test binaries for the target on systems they control. - (Doing so may require enabling some appropriate "developer mode" on such - systems, but must not require the payment of any additional fee or other - consideration, or agreement to any onerous legal agreements.) - - While the Rust project may supply appropriately signed tools, this - requirement exists to ensure that Rust developers can help develop and test - Rust for the target, and that development or testing for the target is not - limited to an exclusive group or entity. - Providing host tools does not exempt a target from requirements to support cross-compilation if at all possible. - All requirements for tier 2 targets with host tools apply. From fcb6ce684170a8b8003f37f1e90b4993b9f57e5d Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 15 Mar 2021 15:11:25 -0700 Subject: [PATCH 117/166] Minor rewording of references to requirements of other tiers Use "requirements for tier N", for consistency with "requirements for tier N with host tools". ("tier N requirements" works, but "tier N with host tools requirements" doesn't work.) --- text/0000-target-tier-policy.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 962af80f3b7..5a74063f5ae 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -352,7 +352,7 @@ by an infrastructure team member reporting the outcome of a team discussion. tests pass for a tier 2 target, even if notified that they fail.) - The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion. -- All tier 3 requirements apply. +- All requirements for tier 3 apply. A tier 2 target may be demoted or removed if it no longer meets these requirements. Any proposal for demotion or removal will be CCed to people who @@ -442,7 +442,7 @@ member reporting the outcome of a team discussion. the host tools. - Providing host tools does not exempt a target from requirements to support cross-compilation if at all possible. -- All tier 2 requirements apply. +- All requirements for tier 2 apply. A target may be promoted directly from tier 3 to tier 2 with host tools if it meets all the necessary requirements, but doing so may introduce substantial @@ -527,7 +527,7 @@ including the infrastructure team in the RFC proposing the target. can help develop and test Rust software for the target (including Rust itself), and that development or testing for the target is not limited to an exclusive group or entity. -- All tier 2 requirements apply. +- All requirements for tier 2 apply. A tier 1 target may be demoted if it no longer meets these requirements but still meets the requirements for a lower tier. Any proposal for demotion of a @@ -594,7 +594,7 @@ team in the RFC proposing the target. - Providing host tools does not exempt a target from requirements to support cross-compilation if at all possible. - All requirements for tier 2 targets with host tools apply. -- All tier 1 requirements apply. +- All requirements for tier 1 apply. A target seeking promotion to tier 1 with host tools should typically either be tier 2 with host tools or tier 1 without host tools, to reduce the number of From 7a6261a3b990d527513ea5ccac082bcbbe0cdb61 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Thu, 18 Mar 2021 21:07:46 -0700 Subject: [PATCH 118/166] Improve clarity of tier 2 summary --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 5a74063f5ae..fd24ca851e6 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -39,7 +39,7 @@ Rust provides three tiers of target support: - Rust provides no guarantees about tier 3 targets; they exist in the codebase, but may or may not build. - Rust's continuous integration checks that tier 2 targets will always build, - but they may not pass tests. + but they may or may not pass tests. - Rust's continuous integration checks that tier 1 targets will always build and pass tests. From d63374afd3cb5dd089f01a766d86b5a0af7aedd8 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Thu, 18 Mar 2021 21:11:38 -0700 Subject: [PATCH 119/166] Provide some information about "host tools" when first mentioned --- text/0000-target-tier-policy.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index fd24ca851e6..06897bb9e27 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -66,10 +66,12 @@ This policy defines the requirements for accepting a proposed target at a given level of support. Each tier builds on all the requirements from the previous tier, unless -overridden by a stronger requirement. Tier 2 and tier 1 also provide additional -requirements to be met if supplying host tools for the target; a target at tier -2 or tier 1 is not required to supply host tools, but if it does, it must meet -the corresponding additional requirements for host tools. +overridden by a stronger requirement. Targets at tier 2 and tier 1 may also +provide *host tools* (such as `rustc` and `cargo`); each of those tiers +includes a set of supplementary requirements that must be met if supplying host +tools for the target. A target at tier 2 or tier 1 is not required to supply +host tools, but if it does, it must meet the corresponding additional +requirements for host tools. The policy for each tier also documents the Rust governance teams that must approve the addition of any target at that tier. Those teams are responsible From d1d29ecc592a04c2129904f40ca40eb3fda6fbac Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Thu, 18 Mar 2021 21:15:26 -0700 Subject: [PATCH 120/166] Sync wording between the start of the guide-level and reference-level sections --- text/0000-target-tier-policy.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 06897bb9e27..ddf4cf4d6cd 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -56,7 +56,8 @@ disruptions to ongoing Rust development. Rust provides three tiers of target support: -- Rust provides no guarantees about tier 3 targets. +- Rust provides no guarantees about tier 3 targets; they exist in the codebase, + but may or may not build. - Rust's continuous integration checks that tier 2 targets will always build, but they may or may not pass tests. - Rust's continuous integration checks that tier 1 targets will always build From 97ce961b657a865ee7d41fcb11f54f1767c295e2 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 22 Mar 2021 19:50:18 -0700 Subject: [PATCH 121/166] Require documentation of limitations to appear in the target tier list A failing test is not prominent enough to give end users sufficient warning. --- text/0000-target-tier-policy.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index ddf4cf4d6cd..48173892b8e 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -310,10 +310,10 @@ by an infrastructure team member reporting the outcome of a team discussion. For example, if Rust relies on a specific code generation feature to support a memory safety property, the code generation for the target should support that feature. If this requirement does not hold, the target must clearly and - prominently document any such limitations, such as via a failing test in the - testsuite and/or a footnote in the target tier list, and the Rust compiler - team must be satisfied with the balance between these limitations and the - difficulty of implementing the necessary features. + prominently document any such limitations as part of the target's entry in + the target tier list, and ideally also via a via a failing test in the + testsuite. The Rust compiler team must be satisfied with the balance between + these limitations and the difficulty of implementing the necessary features. - If the target supports C code, the new Rust target should support the C calling convention for the platform via `extern "C"`. The C calling convention does not need to be the default Rust calling convention for the From 2d5a3976253183bc04a60c0bf47921b42621c508 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 22 Mar 2021 19:57:50 -0700 Subject: [PATCH 122/166] Fix typo ("of providing of") --- text/0000-target-tier-policy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 48173892b8e..257befbbd94 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -345,8 +345,8 @@ by an infrastructure team member reporting the outcome of a team discussion. compatible FOSS terms), such as kernel modules or plugins, then the standard libraries for the target may potentially be subject to copyleft terms, as long as such terms are satisfied by Rust's existing practices of - providing of full corresponding source code. Note that anything added to - the Rust repository itself must still use Rust's standard license terms. + providing full corresponding source code. Note that anything added to the + Rust repository itself must still use Rust's standard license terms. - Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. In particular, do not post comments (automated or manual) on a PR that From d3f9f29185133d4ef2697487bf5c888799ff5f1d Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 22 Mar 2021 19:59:48 -0700 Subject: [PATCH 123/166] Slightly soften a "should" --- text/0000-target-tier-policy.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 257befbbd94..983f2a5b07f 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -110,7 +110,8 @@ requirements for several tiers at once. This policy leaves the precise interpretation of "reasonable amount of time" up to the approving teams; those teams may scale the amount of time required based on their confidence in the target and its demonstrated track record at its current tier. At a minimum, -multiple stable releases of Rust should occur between promotions of a target. +multiple stable releases of Rust should typically occur between promotions of a +target. In this policy, the words "must" and "must not" specify absolute requirements that a target must meet to qualify for a tier. The words "should" and "should From a36998b06a9581cd55a609bc0c74ad844ad548fe Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 22 Mar 2021 20:00:53 -0700 Subject: [PATCH 124/166] Document what happens if the compiler's safety properties broaden --- text/0000-target-tier-policy.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 983f2a5b07f..94c3a66010e 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -315,6 +315,13 @@ by an infrastructure team member reporting the outcome of a team discussion. the target tier list, and ideally also via a via a failing test in the testsuite. The Rust compiler team must be satisfied with the balance between these limitations and the difficulty of implementing the necessary features. + - If the Rust compiler introduces new safety properties (such as via new + capabilities of a compiler backend), the Rust compiler team will determine + if they consider those new safety properties a best-effort improvement for + specific targets, or a required property for all Rust targets. In the + latter case, the compiler team may require the maintainers of existing + targets to either implement and confirm support for the property or update + the target tier list with documentation of the missing property. - If the target supports C code, the new Rust target should support the C calling convention for the platform via `extern "C"`. The C calling convention does not need to be the default Rust calling convention for the From e840d51b79e07da19c6c7db709dac3884a0e7039 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 22 Mar 2021 20:05:29 -0700 Subject: [PATCH 125/166] Demotion or removal will be communicated to the target maintainers Avoid implying that people will actively seek out contributors to the target, rather than relying on an up-to-date list of target maintainers. --- text/0000-target-tier-policy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 94c3a66010e..7ad2e0f007b 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -366,9 +366,9 @@ by an infrastructure team member reporting the outcome of a team discussion. - All requirements for tier 3 apply. A tier 2 target may be demoted or removed if it no longer meets these -requirements. Any proposal for demotion or removal will be CCed to people who -have previously worked on the target, and will be communicated widely to the -Rust community before being dropped from a stable release. +requirements. Any proposal for demotion or removal will be CCed to the target +maintainers, and will be communicated widely to the Rust community before being +dropped from a stable release. In some circumstances, especially if the target maintainers do not respond in a timely fashion, Rust teams may land pull requests that temporarily disable some From 55d3c0cc0d86055806df81057cb0e99313716d0e Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 22 Mar 2021 20:15:46 -0700 Subject: [PATCH 126/166] Fix duplicated phrase --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 7ad2e0f007b..8a5635af922 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -312,7 +312,7 @@ by an infrastructure team member reporting the outcome of a team discussion. a memory safety property, the code generation for the target should support that feature. If this requirement does not hold, the target must clearly and prominently document any such limitations as part of the target's entry in - the target tier list, and ideally also via a via a failing test in the + the target tier list, and ideally also via a failing test in the testsuite. The Rust compiler team must be satisfied with the balance between these limitations and the difficulty of implementing the necessary features. - If the Rust compiler introduces new safety properties (such as via new From e60be23b4929653f13952d6862af6d875f364714 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 22 Mar 2021 20:18:18 -0700 Subject: [PATCH 127/166] Expand language about safety properties; narrow to soundness issues Make it clear this requirement doesn't apply to any arbitrary security feature provided by code generation backends. --- text/0000-target-tier-policy.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 8a5635af922..894b557e92b 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -308,13 +308,17 @@ by an infrastructure team member reporting the outcome of a team discussion. to support those features. - The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team. - For example, if Rust relies on a specific code generation feature to support - a memory safety property, the code generation for the target should support - that feature. If this requirement does not hold, the target must clearly and + (This requirement does not apply to arbitrary security enhancements or + mitigations provided by code generation backends, only to those properties + needed to ensure safe Rust code cannot cause undefined behavior or other + unsoundness.) If this requirement does not hold, the target must clearly and prominently document any such limitations as part of the target's entry in - the target tier list, and ideally also via a failing test in the - testsuite. The Rust compiler team must be satisfied with the balance between - these limitations and the difficulty of implementing the necessary features. + the target tier list, and ideally also via a failing test in the testsuite. + The Rust compiler team must be satisfied with the balance between these + limitations and the difficulty of implementing the necessary features. + - For example, if Rust relies on a specific code generation feature to ensure + that safe code cannot overflow the stack, the code generation for the + target should support that feature. - If the Rust compiler introduces new safety properties (such as via new capabilities of a compiler backend), the Rust compiler team will determine if they consider those new safety properties a best-effort improvement for From 86a25a48e2bb7fec6578b3fea0e0e0965f710cbf Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 22 Mar 2021 20:24:34 -0700 Subject: [PATCH 128/166] Add requirements to not substantially raise the maintenance burden of CI --- text/0000-target-tier-policy.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 894b557e92b..b08be1c488b 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -337,9 +337,10 @@ by an infrastructure team member reporting the outcome of a team discussion. apply if the target builds host tools, or if the tests in question provide substantial value via early detection of critical problems. - Building the target in CI must not take substantially longer than the current - slowest target in CI. This requirement is subjective, to be evaluated by the - infrastructure team, and will take the community importance of the target - into account. + slowest target in CI, and should not substantially raise the maintenance + burden of the CI infrastructure. This requirement is subjective, to be + evaluated by the infrastructure team, and will take the community importance + of the target into account. - New tier 2 targets should, if at all possible, support cross-compiling. New tier 2 targets should not require using the target as the host for builds, even if the target supports host tools. @@ -423,7 +424,8 @@ member reporting the outcome of a team discussion. - The host tools must build and run reliably in CI, though they may or may not pass tests. - Building host tools for the target must not take substantially longer than - building host tools for other targets. + building host tools for other targets, and should not substantially raise the + maintenance burden of the CI infrastructure. - The host tools must provide a substantively similar experience as on other targets, subject to reasonable target limitations. - Adding a substantively different interface to an existing tool, or a @@ -503,7 +505,8 @@ including the infrastructure team in the RFC proposing the target. memory allocation, it must provide an implementation of `alloc` and the associated data structures. - Building the target and running the testsuite for the target must not take - substantially longer than other targets. + substantially longer than other targets, and should not substantially raise + the maintenance burden of the CI infrastructure. - In particular, if building the target takes a reasonable amount of time, but the target cannot run the testsuite in a timely fashion due to low performance of either native code or accurate emulation, that alone may @@ -601,7 +604,8 @@ team in the RFC proposing the target. - The target must not disable an excessive number of tests or pieces of tests in the testsuite in order to do so. This is a subjective requirement. - Building the host tools and running the testsuite for the host tools must not - take substantially longer than other targets. + take substantially longer than other targets, and should not substantially raise + the maintenance burden of the CI infrastructure. - In particular, if building the target's host tools takes a reasonable amount of time, but the target cannot run the testsuite in a timely fashion due to low performance of either native code or accurate emulation, that From 5bd47d10e0942bf9d51f63509ba0dcd9b39fc752 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 22 Mar 2021 22:32:56 -0700 Subject: [PATCH 129/166] Clarification on tier 1 with host tools as evaluated by the release team Make it clear that the release team evaluates the *value* of supporting host tools on the target, rather than the work required to do so. --- text/0000-target-tier-policy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index b08be1c488b..979d3ef28b8 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -568,9 +568,9 @@ development platform, not just a compilation target. A proposed new tier 1 target with host tools must be reviewed and approved by the compiler team based on these requirements. In addition, the release team must approve the long-term viability of host tools for the target, and the -additional work of supporting host tools on the target. For a tier 1 target, -this will typically take place via a full RFC proposing the target, to be -jointly reviewed and approved by the compiler team and release team. +value of supporting host tools on the target. For a tier 1 target, this will +typically take place via a full RFC proposing the target, to be jointly +reviewed and approved by the compiler team and release team. In addition, the infrastructure team must approve the integration of the target's host tools into Continuous Integration (CI), and the CI-related From 10f3d18c6f7fd1f07798e9e8a86a35b67b480127 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 22 Mar 2021 22:35:30 -0700 Subject: [PATCH 130/166] Clarification on tier 1 as evaluated by the release team Make it clear that the release team evaluates the *value* of supporting the target at tier 1, rather than the work required to do so. --- text/0000-target-tier-policy.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 979d3ef28b8..6b2802848fe 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -474,10 +474,10 @@ target. We hold tier 1 targets to our highest standard of requirements. A proposed new tier 1 target must be reviewed and approved by the compiler team based on these requirements. In addition, the release team must approve the -long-term viability of the target, and the additional work of supporting the -target. For a tier 1 target, this will typically take place via a full RFC -proposing the target, to be jointly reviewed and approved by the compiler team -and release team. +long-term viability of the target, and the value of supporting the target. For +a tier 1 target, this will typically take place via a full RFC proposing the +target, to be jointly reviewed and approved by the compiler team and release +team. In addition, the infrastructure team must approve the integration of the target into Continuous Integration (CI), and the tier 1 CI-related requirements. This From 774005617fb97d3d22bf12fa908fbb40a33c4e35 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 23 Mar 2021 15:33:54 -0700 Subject: [PATCH 131/166] Update tier 2 requirement about not blocking PRs to match tier 3 language --- text/0000-target-tier-policy.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 6b2802848fe..0e84dcad635 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -366,6 +366,10 @@ by an infrastructure team member reporting the outcome of a team discussion. suggests a block on the PR based on tests failing for the target. (A PR author must not break the build of a tier 2 target, but need not ensure the tests pass for a tier 2 target, even if notified that they fail.) + - It is acceptable to manually initiate or link to a discussion about how to + make a PR and a tier 2 target compatible, but that discussion must not be + implied to block the PR unless either the PR author or PR approver want it + to be. - The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion. - All requirements for tier 3 apply. From 1df171435611af188789887668bbbfd7834945cf Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 23 Mar 2021 16:06:41 -0700 Subject: [PATCH 132/166] Make requirements about unwanted messages more strict Even a well-intentioned comment on a PR stating that it breaks a tier 2/3 target can still derail the PR, and developers may not be aware that they don't need to act on such messages. Drop the exception and tighten the language. Add a note that automated messages or notifications *outside* the PR thread are not OK either, lest someone generate emails to PR authors instead, or generate issues elsewhere that `@` the PR author. Add a note that backlinks (such as those generated by GitHub whenever linking to a PR) are acceptable within reason. Otherwise, target developers on a separate repository could not even link to a PR as part of coordination. --- text/0000-target-tier-policy.md | 35 +++++++++++++++++++-------------- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 0e84dcad635..9522ca53c11 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -214,13 +214,16 @@ approved by the appropriate team for that shared code before acceptance. dedicated hardware if necessary. - Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, - do not post comments (automated or manual) on a PR that suggests a block on - the PR based on the target. (A PR author may choose to help with a tier 3 - target, but is not required to.) - - It is acceptable to manually initiate or link to a discussion about how to - make a PR and a tier 3 target compatible, but that discussion must not be - implied to block the PR unless either the PR author or PR approver want it - to be. + do not post comments (automated or manual) on a PR that derail or suggest a + block on the PR based on the target. Do not send automated messages or + notifications (via any medium, including via `@`) to a PR author or others + involved with a PR regarding a tier 3 target, unless they have opted into + such messages. + - Backlinks such as those generated by the issue/PR tracker when linking to + an issue or PR are not considered a violation of this policy, within + reason. However, such messages (even on a separate repository) must not + generate notifications to anyone involved with a PR who has not requested + such notifications. - Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target. @@ -362,14 +365,16 @@ by an infrastructure team member reporting the outcome of a team discussion. Rust repository itself must still use Rust's standard license terms. - Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target. - In particular, do not post comments (automated or manual) on a PR that - suggests a block on the PR based on tests failing for the target. (A PR - author must not break the build of a tier 2 target, but need not ensure the - tests pass for a tier 2 target, even if notified that they fail.) - - It is acceptable to manually initiate or link to a discussion about how to - make a PR and a tier 2 target compatible, but that discussion must not be - implied to block the PR unless either the PR author or PR approver want it - to be. + In particular, do not post comments (automated or manual) on a PR that derail + or suggest a block on the PR based on tests failing for the target. Do not + send automated messages or notifications (via any medium, including via `@`) + to a PR author or others involved with a PR regarding the PR breaking tests + on a tier 2 target, unless they have opted into such messages. + - Backlinks such as those generated by the issue/PR tracker when linking to + an issue or PR are not considered a violation of this policy, within + reason. However, such messages (even on a separate repository) must not + generate notifications to anyone involved with a PR who has not requested + such notifications. - The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion. - All requirements for tier 3 apply. From 0f25999018074f216bb1195d606d70a431f71540 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 23 Mar 2021 16:37:50 -0700 Subject: [PATCH 133/166] Add some subjectivity regarding communications of target demotion/removal If breakage occurs close to a stable release, and cannot be fixed in a timely fashion, we may not be able to provide much notice; allow for that possibility, even though we would try to avoid it. --- text/0000-target-tier-policy.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 9522ca53c11..5f39a31502a 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -382,7 +382,10 @@ by an infrastructure team member reporting the outcome of a team discussion. A tier 2 target may be demoted or removed if it no longer meets these requirements. Any proposal for demotion or removal will be CCed to the target maintainers, and will be communicated widely to the Rust community before being -dropped from a stable release. +dropped from a stable release. (The amount of time between such communication +and the next stable release may depend on the nature and severity of the failed +requirement, the timing of its discovery, and whether the demotion or removal +can be a planned and scheduled action.) In some circumstances, especially if the target maintainers do not respond in a timely fashion, Rust teams may land pull requests that temporarily disable some @@ -562,7 +565,10 @@ tier 1 target requires a full RFC process, with approval by the compiler and release teams. Any such proposal will be communicated widely to the Rust community, both when initially proposed and before being dropped from a stable release. A tier 1 target is highly unlikely to be directly removed without -first being demoted to tier 2 or tier 3. +first being demoted to tier 2 or tier 3. (The amount of time between such +communication and the next stable release may depend on the nature and severity +of the failed requirement, the timing of its discovery, and whether the +demotion or removal can be a planned and scheduled action.) Raising the baseline expectations of a tier 1 target (such as the minimum CPU features or OS version required) requires the approval of the compiler and From afd1240e5c624e6598aa7f97ee37c3779ff8d163 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 23 Mar 2021 16:43:11 -0700 Subject: [PATCH 134/166] Allow for targets implementing std without having a full OS Some targets may have a layer of system-provided functionality that isn't exactly an operating system. --- text/0000-target-tier-policy.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 5f39a31502a..fa21258291f 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -202,11 +202,12 @@ approved by the appropriate team for that shared code before acceptance. - Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (`core` for most targets, `alloc` for targets that can support dynamic memory allocation, `std` for targets with an - operating system), but may leave some code unimplemented (either unavailable - or stubbed out as appropriate), whether because the target makes it - impossible to implement or challenging to implement. The authors of pull - requests are not obligated to avoid calling any portions of the standard - library on the basis of a tier 3 target not implementing those portions. + operating system or equivalent layer of system-provided functionality), but + may leave some code unimplemented (either unavailable or stubbed out as + appropriate), whether because the target makes it impossible to implement or + challenging to implement. The authors of pull requests are not obligated to + avoid calling any portions of the standard library on the basis of a tier 3 + target not implementing those portions. - The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must From f41e11483cd90b511e5564a0748283784e2a9c6e Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 23 Mar 2021 16:46:00 -0700 Subject: [PATCH 135/166] Clarify tier 3 requirement about breaking other tier 3 targets Specify "knowingly break", to avoid implying that PRs adding or updating tier 3 targets have any obligation to build or test other tier 3 targets. This requirement exists to cover knowing breakage, not to impose an additional testing burden. --- text/0000-target-tier-policy.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index fa21258291f..a06aab1af24 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -226,8 +226,9 @@ approved by the appropriate team for that shared code before acceptance. generate notifications to anyone involved with a PR who has not requested such notifications. - Patches adding or updating tier 3 targets must not break any existing tier 2 - or tier 1 target, and must not break another tier 3 target without approval - of either the compiler team or the maintainers of the other tier 3 target. + or tier 1 target, and must not knowingly break another tier 3 target without + approval of either the compiler team or the maintainers of the other tier 3 + target. - In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the From 39c73e8569957682a0a68e24fd1e64b88ea662e7 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 23 Mar 2021 17:06:09 -0700 Subject: [PATCH 136/166] Drop "new" as a qualifier for rules intended to apply to existing targets In particular, we don't need the "new" qualifier on any "should" rule, since we can already grant exceptions to a "should". --- text/0000-target-tier-policy.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index a06aab1af24..50f41785e73 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -134,9 +134,9 @@ A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance. -- Any new tier 3 target must have a designated developer or developers (the - "target maintainers") on record to be CCed when issues arise regarding the - target. (The mechanism to track and CC such developers may evolve over time.) +- A tier 3 target must have a designated developer or developers (the "target + maintainers") on record to be CCed when issues arise regarding the target. + (The mechanism to track and CC such developers may evolve over time.) - Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and @@ -157,7 +157,7 @@ approved by the appropriate team for that shared code before acceptance. - Anything added to the Rust repository must be under the standard Rust license (`MIT OR Apache-2.0`). - The target must not cause the Rust tools or libraries built for any other - host (even when supporting cross-compilation to the new target) to depend + host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by `src/tools/tidy/src/deps.rs` in the @@ -174,7 +174,7 @@ approved by the appropriate team for that shared code before acceptance. library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3. - - New targets should not require proprietary (non-FOSS) components to link a + - Targets should not require proprietary (non-FOSS) components to link a functional binary or library. - "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are *not* limited to: non-disclosure @@ -260,7 +260,7 @@ by an infrastructure team member reporting the outcome of a team discussion. - A tier 2 target must have value to people other than its maintainers. (It may still be a niche target, but it must not be exclusively useful for an inherently closed group.) -- Any new tier 2 target must have a designated team of developers (the "target +- A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers. @@ -331,10 +331,9 @@ by an infrastructure team member reporting the outcome of a team discussion. latter case, the compiler team may require the maintainers of existing targets to either implement and confirm support for the property or update the target tier list with documentation of the missing property. -- If the target supports C code, the new Rust target should support the C - calling convention for the platform via `extern "C"`. The C calling - convention does not need to be the default Rust calling convention for the - target, however. +- If the target supports C code, the Rust target should support the C calling + convention for the platform via `extern "C"`. The C calling convention does + not need to be the default Rust calling convention for the target, however. - The target must build reliably in CI. - The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional "hello world" program, `./x.py test @@ -346,9 +345,9 @@ by an infrastructure team member reporting the outcome of a team discussion. burden of the CI infrastructure. This requirement is subjective, to be evaluated by the infrastructure team, and will take the community importance of the target into account. -- New tier 2 targets should, if at all possible, support cross-compiling. New - tier 2 targets should not require using the target as the host for builds, - even if the target supports host tools. +- Tier 2 targets should, if at all possible, support cross-compiling. Tier 2 + targets should not require using the target as the host for builds, even if + the target supports host tools. - In addition to the legal requirements for all targets (specified in the tier 3 requirements), because a tier 2 target typically involves the Rust project building and supplying various compiled binaries, incorporating the target From ba9d93e65e5b72eb4db7fdfc21a628e0e93bdc37 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 23 Mar 2021 23:00:56 -0700 Subject: [PATCH 137/166] Clarify recusal --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 50f41785e73..235253f8ab0 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -190,7 +190,7 @@ approved by the appropriate team for that shared code before acceptance. Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval - process regarding the target's tier status, though they may otherwise + decisions regarding the target's tier status, though they may otherwise participate in discussions. - This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or From d23c1aed0b5e872b59c01b4b5859f39c955fa2f1 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 23 Mar 2021 23:37:24 -0700 Subject: [PATCH 138/166] Minor wording tweaks in future possibilities --- text/0000-target-tier-policy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 235253f8ab0..cda08124af9 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -700,11 +700,11 @@ issue is labeled with a target-specific label. Eventually, as more targets seek tier 1 status, we may want to document more criteria used to evaluate requirements such as "long-term viability of the -target". We should also update these requirements if corner cases arise. +target". We should also update these requirements whenever corner cases arise. Some of our existing targets may not meet all of these criteria today. We may -wish to audit existing targets against these criteria, but this RFC does not -constitute a commitment to do so in a timely fashion. +audit existing targets against these criteria, but this RFC does not constitute +a commitment to do so in a timely fashion. In the future, we may have a specified approval body for evaluating legal requirements, in consultation with legal professionals. From db9e8e62abe6d2706ce94b2d3b322ea09cb077ca Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 23 Mar 2021 23:38:31 -0700 Subject: [PATCH 139/166] Future possibilities: Document scope and potential communication improvements --- text/0000-target-tier-policy.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index cda08124af9..a135d2e23e8 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -702,6 +702,15 @@ Eventually, as more targets seek tier 1 status, we may want to document more criteria used to evaluate requirements such as "long-term viability of the target". We should also update these requirements whenever corner cases arise. +These requirements intentionally don't address the problem of scaling Rust to a +huge volume of targets, where no one target causes a burden but all of them +taken together do, and we may need to adapt and adjust accordingly. + +We need to improve our methods of communicating Rust support levels to +downstream users, especially people who may be relying indirectly on a +non-tier-1 Rust target and who may have expectations that do not match the +target tier. + Some of our existing targets may not meet all of these criteria today. We may audit existing targets against these criteria, but this RFC does not constitute a commitment to do so in a timely fashion. From be98dd63c7ac3f6ac19054661f1e2f8baf06c019 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 00:18:28 -0700 Subject: [PATCH 140/166] Fix spacing --- text/0000-target-tier-policy.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index a135d2e23e8..cf720a699ca 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -116,7 +116,7 @@ target. In this policy, the words "must" and "must not" specify absolute requirements that a target must meet to qualify for a tier. The words "should" and "should not" specify requirements that apply in almost all cases, but for which the -approving teams may grant an exception for good reason. The word "may" +approving teams may grant an exception for good reason. The word "may" indicates something entirely optional, and does not indicate guidance or recommendations. This language is based on [IETF RFC 2119](https://tools.ietf.org/html/rfc2119). @@ -425,7 +425,7 @@ member reporting the outcome of a team discussion. build the host tools, and the substantial additional storage required for the host tools. - The host tools must have direct value to people other than the target's - maintainers. (It may still be a niche target, but the host tools must not be + maintainers. (It may still be a niche target, but the host tools must not be exclusively useful for an inherently closed group.) This requirement will be evaluated independently from the corresponding tier 2 requirement. - The requirement to provide "direct value" means that it does not suffice to @@ -462,7 +462,7 @@ member reporting the outcome of a team discussion. "developer mode" or an additional prompt), it must be possible for the Rust project's automated builds to apply the appropriate signature process, without any manual intervention by either Rust developers, target - maintainers, or a third party. This process must meet the approval of the + maintainers, or a third party. This process must meet the approval of the infrastructure team. - This process may require one-time or semi-regular manual steps by the infrastructure team, such as registration or renewal of a signing key. Any @@ -546,7 +546,7 @@ including the infrastructure team in the RFC proposing the target. developers to make target-specific fixes.) - New tier 1 targets must not have a hard requirement for signed, verified, or otherwise "approved" binaries. Developers must be able to build, run, and - test binaries for the target on systems they control. (Doing so may require + test binaries for the target on systems they control. (Doing so may require enabling some appropriate "developer mode" on such systems, but must not require the payment of any additional fee or other consideration, or agreement to any onerous legal agreements.) From 335035653f075785ba7f4549ba0e6341fa4d37f1 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 00:18:39 -0700 Subject: [PATCH 141/166] Allow for revocable agreements for signing keys --- text/0000-target-tier-policy.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index cf720a699ca..246b84b27fb 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -467,6 +467,12 @@ member reporting the outcome of a team discussion. - This process may require one-time or semi-regular manual steps by the infrastructure team, such as registration or renewal of a signing key. Any such manual process must meet the approval of the infrastructure team. + - This process may require the execution of a legal agreement with the + signature provider. Such a legal agreement may be revocable, but must not + be otherwise onerous. Any such legal agreement must meet the approval of + the infrastructure team. + - Changes to this process, or to any legal agreements involved, may + cause a target to stop meeting this requirement. - This requirement exists to ensure that Rust builds, including nightly builds, can meet the necessary requirements to allow users to smoothly run the host tools. From c1742686432d34766ac8ded35ffcef9a8c963b59 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 00:25:07 -0700 Subject: [PATCH 142/166] Require that signing processes be available to others as well --- text/0000-target-tier-policy.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 246b84b27fb..351b5a96314 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -473,6 +473,9 @@ member reporting the outcome of a team discussion. the infrastructure team. - Changes to this process, or to any legal agreements involved, may cause a target to stop meeting this requirement. + - This process involved must be available under substantially similar + non-onerous terms to the general public. Making it available exclusively to + the Rust project does not suffice. - This requirement exists to ensure that Rust builds, including nightly builds, can meet the necessary requirements to allow users to smoothly run the host tools. From a870b01875ea4bbd59e86e12155f69616aff806e Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 00:28:01 -0700 Subject: [PATCH 143/166] Allow signing-related agreements to involve a nominal fee "nominal" is intentionally subjective. --- text/0000-target-tier-policy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 351b5a96314..7dec1afa7d5 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -468,9 +468,9 @@ member reporting the outcome of a team discussion. infrastructure team, such as registration or renewal of a signing key. Any such manual process must meet the approval of the infrastructure team. - This process may require the execution of a legal agreement with the - signature provider. Such a legal agreement may be revocable, but must not - be otherwise onerous. Any such legal agreement must meet the approval of - the infrastructure team. + signature provider. Such a legal agreement may be revocable, and may + potentially require a nominal fee, but must not be otherwise onerous. Any + such legal agreement must meet the approval of the infrastructure team. - Changes to this process, or to any legal agreements involved, may cause a target to stop meeting this requirement. - This process involved must be available under substantially similar From 65f51481421f508199e6ef941be951d1b9f50721 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 00:33:20 -0700 Subject: [PATCH 144/166] Drop "new" qualifier on requirement to allow developers to run their own binaries No existing tier 1 target has a hard requirement for this, so we don't need an exception for existing targets. --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 7dec1afa7d5..99027f8586b 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -553,7 +553,7 @@ including the infrastructure team in the RFC proposing the target. maintainers. This requirement ensures that it is possible for other Rust developers to test the target, but does not obligate other Rust developers to make target-specific fixes.) -- New tier 1 targets must not have a hard requirement for signed, verified, or +- Tier 1 targets must not have a hard requirement for signed, verified, or otherwise "approved" binaries. Developers must be able to build, run, and test binaries for the target on systems they control. (Doing so may require enabling some appropriate "developer mode" on such systems, but must not From 71ce094359a32225d8faa4c78aeac281ba652194 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 00:43:46 -0700 Subject: [PATCH 145/166] Simplify language about developers running their own binaries --- text/0000-target-tier-policy.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 99027f8586b..2eb2ef8e168 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -564,9 +564,8 @@ including the infrastructure team in the RFC proposing the target. and a tier 2 target with host tools already requires providing appropriate mechanisms that enable our infrastructure to provide such signed binaries. However, this additional tier 1 requirement ensures that Rust developers - can help develop and test Rust software for the target (including Rust - itself), and that development or testing for the target is not limited to - an exclusive group or entity. + can develop and test Rust software for the target (including Rust itself), + and that development or testing for the target is not limited. - All requirements for tier 2 apply. A tier 1 target may be demoted if it no longer meets these requirements but From 548de23ce7020ea39a01cc907487a8b68a72b768 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 00:44:37 -0700 Subject: [PATCH 146/166] Ensure that developers can give binaries to others, as well --- text/0000-target-tier-policy.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 2eb2ef8e168..ecbc79cc56e 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -555,10 +555,11 @@ including the infrastructure team in the RFC proposing the target. developers to make target-specific fixes.) - Tier 1 targets must not have a hard requirement for signed, verified, or otherwise "approved" binaries. Developers must be able to build, run, and - test binaries for the target on systems they control. (Doing so may require - enabling some appropriate "developer mode" on such systems, but must not - require the payment of any additional fee or other consideration, or - agreement to any onerous legal agreements.) + test binaries for the target on systems they control, or provide such + binaries for others to run. (Doing so may require enabling some appropriate + "developer mode" on such systems, but must not require the payment of any + additional fee or other consideration, or agreement to any onerous legal + agreements.) - The Rust project may decide to supply appropriately signed binaries if doing so provides a smoother experience for developers using the target, and a tier 2 target with host tools already requires providing appropriate From d6c6f1fe33e31c753a5152375dce69fc8c158dc8 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 00:56:03 -0700 Subject: [PATCH 147/166] Document availability requirements for CI and non-CI resources --- text/0000-target-tier-policy.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index ecbc79cc56e..761f7fd653f 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -553,6 +553,11 @@ including the infrastructure team in the RFC proposing the target. maintainers. This requirement ensures that it is possible for other Rust developers to test the target, but does not obligate other Rust developers to make target-specific fixes.) + - Resources provided for CI and similar infrastructure must be available for + continuous exclusive use by the Rust project. Resources provided + for access by Rust team members for development and testing must be + available on an exclusive basis when in use, but need not be available on a + continuous basis when not in use. - Tier 1 targets must not have a hard requirement for signed, verified, or otherwise "approved" binaries. Developers must be able to build, run, and test binaries for the target on systems they control, or provide such From c1f669b5ac7c284529371cf07960f2315a7cf50b Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 01:12:35 -0700 Subject: [PATCH 148/166] Expand target maintainer team size for tier 1 --- text/0000-target-tier-policy.md | 1 + 1 file changed, 1 insertion(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 761f7fd653f..7927364ffe4 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -513,6 +513,7 @@ including the infrastructure team in the RFC proposing the target. are subjective, and determined by consensus of the approving teams. A tier 1 target may be demoted or removed if it becomes obsolete or no longer meets this requirement. +- The target maintainer team must include at least 3 developers. - The target must build and pass tests reliably in CI. - The target must not disable an excessive number of tests or pieces of tests in the testsuite in order to do so. This is a subjective requirement. From 376adda43fe01278ef09d60b250a0ede88d4e083 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 01:12:46 -0700 Subject: [PATCH 149/166] Change "their documentation" to just "documentation" Enhancing other documentation of the target is welcome and encouraged. --- text/0000-target-tier-policy.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 7927364ffe4..b1719f339a0 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -266,8 +266,7 @@ by an infrastructure team member reporting the outcome of a team discussion. details. This team must have at least 2 developers. - The target maintainers should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community - about portability to their target, and enhance their documentation of the - target. + about portability to their target, and enhance documentation of the target. - The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers are expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 From 39e3299fa49623b61d1cfc879be7d60a244ecc60 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 01:20:39 -0700 Subject: [PATCH 150/166] Change "may" to "should" in note that we should audit existing targets --- text/0000-target-tier-policy.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index b1719f339a0..e6117b7fee4 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -725,9 +725,9 @@ downstream users, especially people who may be relying indirectly on a non-tier-1 Rust target and who may have expectations that do not match the target tier. -Some of our existing targets may not meet all of these criteria today. We may -audit existing targets against these criteria, but this RFC does not constitute -a commitment to do so in a timely fashion. +Some of our existing targets may not meet all of these criteria today. We +should audit existing targets against these criteria, but this RFC does not +constitute a commitment to do so in a timely fashion. In the future, we may have a specified approval body for evaluating legal requirements, in consultation with legal professionals. From f21ed7716476ed6280621da7df4948dddc28a84b Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 01:25:37 -0700 Subject: [PATCH 151/166] Expand text about auditing existing targets --- text/0000-target-tier-policy.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index e6117b7fee4..c6b8f32b679 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -726,8 +726,12 @@ non-tier-1 Rust target and who may have expectations that do not match the target tier. Some of our existing targets may not meet all of these criteria today. We -should audit existing targets against these criteria, but this RFC does not -constitute a commitment to do so in a timely fashion. +should audit existing targets against these criteria. This RFC does not +constitute a commitment to do so in a timely fashion, but there's substantial +value in formally confirming the eligibility of existing targets, to remove +uncertainty about the support level of those targets. Once this RFC is +accepted, targets that have not been evaluated against this criteria should +have an indication of this on the Rust Platform Support page. In the future, we may have a specified approval body for evaluating legal requirements, in consultation with legal professionals. From f6d1a37f09b56f97a626f1eaf47ba15fc145b55b Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 01:39:13 -0700 Subject: [PATCH 152/166] Change "long-term viability" to just "viability", and combine with "value" --- text/0000-target-tier-policy.md | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index c6b8f32b679..244e36be8c1 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -495,10 +495,9 @@ target. We hold tier 1 targets to our highest standard of requirements. A proposed new tier 1 target must be reviewed and approved by the compiler team based on these requirements. In addition, the release team must approve the -long-term viability of the target, and the value of supporting the target. For -a tier 1 target, this will typically take place via a full RFC proposing the -target, to be jointly reviewed and approved by the compiler team and release -team. +viability and value of supporting the target. For a tier 1 target, this will +typically take place via a full RFC proposing the target, to be jointly +reviewed and approved by the compiler team and release team. In addition, the infrastructure team must approve the integration of the target into Continuous Integration (CI), and the tier 1 CI-related requirements. This @@ -597,10 +596,10 @@ development platform, not just a compilation target. A proposed new tier 1 target with host tools must be reviewed and approved by the compiler team based on these requirements. In addition, the release team -must approve the long-term viability of host tools for the target, and the -value of supporting host tools on the target. For a tier 1 target, this will -typically take place via a full RFC proposing the target, to be jointly -reviewed and approved by the compiler team and release team. +must approve the viability and value of supporting host tools for the target. +For a tier 1 target, this will typically take place via a full RFC proposing +the target, to be jointly reviewed and approved by the compiler team and +release team. In addition, the infrastructure team must approve the integration of the target's host tools into Continuous Integration (CI), and the CI-related From d747f54cc50671e370ac83d97f3991c5da1785bc Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 01:47:32 -0700 Subject: [PATCH 153/166] Expand discussion about documenting subjective requirements --- text/0000-target-tier-policy.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 244e36be8c1..7b57ae406de 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -712,8 +712,10 @@ issue is labeled with a target-specific label. [future-possibilities]: #future-possibilities Eventually, as more targets seek tier 1 status, we may want to document more -criteria used to evaluate requirements such as "long-term viability of the -target". We should also update these requirements whenever corner cases arise. +criteria used to evaluate subjective requirements such as "viability and value +of supporting the target". We should also update these requirements whenever +corner cases arise. However, the subjective requirements should remain, to +provide ample room for human judgment. These requirements intentionally don't address the problem of scaling Rust to a huge volume of targets, where no one target causes a burden but all of them From 919da1a490360b4b9b015b1b1ff23546ca4b158a Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 02:14:20 -0700 Subject: [PATCH 154/166] For communications, add "whether the target has been part of a stable 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. --- text/0000-target-tier-policy.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 7b57ae406de..9229b3213b5 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -384,8 +384,9 @@ requirements. Any proposal for demotion or removal will be CCed to the target maintainers, and will be communicated widely to the Rust community before being dropped from a stable release. (The amount of time between such communication and the next stable release may depend on the nature and severity of the failed -requirement, the timing of its discovery, and whether the demotion or removal -can be a planned and scheduled action.) +requirement, the timing of its discovery, whether the target has been part of a +stable release yet, and whether the demotion or removal can be a planned and +scheduled action.) In some circumstances, especially if the target maintainers do not respond in a timely fashion, Rust teams may land pull requests that temporarily disable some @@ -581,8 +582,9 @@ community, both when initially proposed and before being dropped from a stable release. A tier 1 target is highly unlikely to be directly removed without first being demoted to tier 2 or tier 3. (The amount of time between such communication and the next stable release may depend on the nature and severity -of the failed requirement, the timing of its discovery, and whether the -demotion or removal can be a planned and scheduled action.) +of the failed requirement, the timing of its discovery, whether the target has +been part of a stable release yet, and whether the demotion or removal can be a +planned and scheduled action.) Raising the baseline expectations of a tier 1 target (such as the minimum CPU features or OS version required) requires the approval of the compiler and From 8fb49e14ddf7a19d9e06d770225ab62c152b2d48 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 24 Mar 2021 02:23:58 -0700 Subject: [PATCH 155/166] Add some discussion about target tier stability guarantees --- text/0000-target-tier-policy.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 9229b3213b5..baa82b3ee16 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -113,6 +113,13 @@ target and its demonstrated track record at its current tier. At a minimum, multiple stable releases of Rust should typically occur between promotions of a target. +The availability or tier of a target in stable Rust is not a hard stability +guarantee about the future availability or tier of that target. Higher-level +target tiers are an increasing commitment to the support of a target, and we +will take that commitment and potential disruptions into account when +evaluating the potential demotion or removal of a target that has been part of +a stable release. + In this policy, the words "must" and "must not" specify absolute requirements that a target must meet to qualify for a tier. The words "should" and "should not" specify requirements that apply in almost all cases, but for which the @@ -728,6 +735,10 @@ downstream users, especially people who may be relying indirectly on a non-tier-1 Rust target and who may have expectations that do not match the target tier. +This RFC provides some guidance on the degree of stability we provide regarding +the availability and tier of a target. We should provide additional guidance on +this in the future. + Some of our existing targets may not meet all of these criteria today. We should audit existing targets against these criteria. This RFC does not constitute a commitment to do so in a timely fashion, but there's substantial From 40ed9f8ca0463d0b1edd558166be0054fea1a4d3 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Mon, 5 Apr 2021 13:08:59 -0700 Subject: [PATCH 156/166] Make C interoperability a "must" at tier 2 Make this requirement conditional on the target having an interoperable calling convention for C code. --- text/0000-target-tier-policy.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index baa82b3ee16..857aa33cdbf 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -337,9 +337,10 @@ by an infrastructure team member reporting the outcome of a team discussion. latter case, the compiler team may require the maintainers of existing targets to either implement and confirm support for the property or update the target tier list with documentation of the missing property. -- If the target supports C code, the Rust target should support the C calling - convention for the platform via `extern "C"`. The C calling convention does - not need to be the default Rust calling convention for the target, however. +- If the target supports C code, and the target has an interoperable calling + convention for C code, the Rust target must support that C calling convention + for the platform via `extern "C"`. The C calling convention does not need to + be the default Rust calling convention for the target, however. - The target must build reliably in CI. - The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional "hello world" program, `./x.py test From c394f76214d154c15adebead78411faae9ab5105 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 6 Apr 2021 14:26:57 -0700 Subject: [PATCH 157/166] Add an exception allowing non-implementation of std in specific cases 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. --- text/0000-target-tier-policy.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 857aa33cdbf..3ca75ad86e9 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -317,6 +317,12 @@ by an infrastructure team member reporting the outcome of a team discussion. some cases, a target may be co-developed along with Rust support, and Rust may gain new features on the target as that target gains the capabilities to support those features. + - As an exception, a target identical to an existing tier 1 target except for + lower baseline expectations for the OS, CPU, or similar, may propose to + qualify as tier 2 (but not higher) without support for `std` if the target + will primarily be used in `no_std` applications, to reduce the support + burden for the standard library. In this case, evaluation of the proposed + target's value will take this limitation into account. - The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team. (This requirement does not apply to arbitrary security enhancements or From da764cd8114d9da2d69838466706d4b670e4bdcf Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 6 Apr 2021 14:29:17 -0700 Subject: [PATCH 158/166] Add a missing "tier 3" qualifier on a tier 3 requirement Make it even more clear that this requirement only applies to tier 3, not to higher tiers (which otherwise inherit lower-tier requirements). --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 3ca75ad86e9..7e15cc5be97 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -223,7 +223,7 @@ approved by the appropriate team for that shared code before acceptance. - Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a - block on the PR based on the target. Do not send automated messages or + block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via `@`) to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages. From 9f793b99a51c1e45c488b170be0a2186bc3c4627 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 6 Apr 2021 19:28:41 -0700 Subject: [PATCH 159/166] Clarify that infra is not personally responsible for signing legal agreements --- text/0000-target-tier-policy.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 7e15cc5be97..66261417afb 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -485,6 +485,11 @@ member reporting the outcome of a team discussion. signature provider. Such a legal agreement may be revocable, and may potentially require a nominal fee, but must not be otherwise onerous. Any such legal agreement must meet the approval of the infrastructure team. + (The infrastructure team is not expected or required to sign binding legal + agreements on behalf of the Rust project; this review and approval exists + to ensure no terms are onerous or cause problems for infrastructure, + especially if such terms may impose requirements or obligations on people + who have access to target-specific infrastructure.) - Changes to this process, or to any legal agreements involved, may cause a target to stop meeting this requirement. - This process involved must be available under substantially similar From 8e3e9c39c2fcbbbf4520fe52108e8c25bb675081 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 6 Apr 2021 19:32:36 -0700 Subject: [PATCH 160/166] Update URL for platform support page --- text/0000-target-tier-policy.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 66261417afb..4cadf53bc4c 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -24,12 +24,13 @@ occasionally ask what it would take to add a new tier 1 target. The Rust project has no clear policy for target tiers. People not only don't know, they don't know who to ask or where to start. -See for more +See for more information about targets and tiers. -Once accepted, the policy sections of this RFC should be posted on - in a "Target Tier Policy" section; this RFC will -not be the canonical home of the up-to-date target tier policy. +Once accepted, the policy sections of this RFC should be posted alongside + in a "Target +Tier Policy" section; this RFC will not be the canonical home of the up-to-date +target tier policy. # Guide-level explanation [guide-level-explanation]: #guide-level-explanation @@ -101,7 +102,7 @@ requirements. All supported targets and their corresponding tiers ("tier 3", "tier 2", "tier 2 with host tools", "tier 1", or "tier 1 with host tools") will be documented on an appropriate official page, such as -. +. Note that a target must have already received approval for the next lower tier, and spent a reasonable amount of time at that tier, before making a proposal @@ -710,7 +711,7 @@ unlikely to provide value commensurate with that confusion. This attempts to formalize and document Rust policy around targets and architectures. Some requirements of such a policy appear on the [Rust Platform -Support page](https://forge.rust-lang.org/release/platform-support.html). +Support page](https://doc.rust-lang.org/nightly/rustc/platform-support.html). Future expansions of such policy may find requirements from other communities useful as examples, such as Debian's [arch From 0ee5875fc1cdadb6ca8cdbad99761e18de8de2d8 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 6 Apr 2021 19:42:23 -0700 Subject: [PATCH 161/166] Promotion/demotion doesn't typically affect past releases --- text/0000-target-tier-policy.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 4cadf53bc4c..c7b980aec25 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -119,7 +119,8 @@ guarantee about the future availability or tier of that target. Higher-level target tiers are an increasing commitment to the support of a target, and we will take that commitment and potential disruptions into account when evaluating the potential demotion or removal of a target that has been part of -a stable release. +a stable release. The promotion or demotion of a target will not generally +affect existing stable releases, only current development and future releases. In this policy, the words "must" and "must not" specify absolute requirements that a target must meet to qualify for a tier. The words "should" and "should From bf5f44e0e4282f07f899c4b90db9f8dc71adddcf Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 6 Apr 2021 19:42:38 -0700 Subject: [PATCH 162/166] Qualify mentions of CI to include all components Rust's CI considers mandatory --- text/0000-target-tier-policy.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index c7b980aec25..2ee3d11d901 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -349,7 +349,8 @@ by an infrastructure team member reporting the outcome of a team discussion. convention for C code, the Rust target must support that C calling convention for the platform via `extern "C"`. The C calling convention does not need to be the default Rust calling convention for the target, however. -- The target must build reliably in CI. +- The target must build reliably in CI, for all components that Rust's CI + considers mandatory. - The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional "hello world" program, `./x.py test --no-run`, or equivalent "smoke tests". In particular, this requirement may @@ -450,8 +451,8 @@ member reporting the outcome of a team discussion. others. - There must be a reasonable expectation that the host tools will be used, for purposes other than to prove that they can be used. -- The host tools must build and run reliably in CI, though they may or may not - pass tests. +- The host tools must build and run reliably in CI (for all components that + Rust's CI considers mandatory), though they may or may not pass tests. - Building host tools for the target must not take substantially longer than building host tools for other targets, and should not substantially raise the maintenance burden of the CI infrastructure. @@ -534,7 +535,8 @@ including the infrastructure team in the RFC proposing the target. target may be demoted or removed if it becomes obsolete or no longer meets this requirement. - The target maintainer team must include at least 3 developers. -- The target must build and pass tests reliably in CI. +- The target must build and pass tests reliably in CI, for all components that + Rust's CI considers mandatory. - The target must not disable an excessive number of tests or pieces of tests in the testsuite in order to do so. This is a subjective requirement. - If the target does not have host tools support, or if the target has low @@ -652,7 +654,8 @@ team in the RFC proposing the target. sufficient interest for cross-compilation, but not have sufficient interest for native compilation. The host tools may be dropped if they no longer meet this requirement, even if the target otherwise qualifies as tier 1. -- The host tools must build, run, and pass tests reliably in CI. +- The host tools must build, run, and pass tests reliably in CI, for all + components that Rust's CI considers mandatory. - The target must not disable an excessive number of tests or pieces of tests in the testsuite in order to do so. This is a subjective requirement. - Building the host tools and running the testsuite for the host tools must not From d13349ea028521ca0152216401a9027edc7e5725 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 6 Apr 2021 19:57:28 -0700 Subject: [PATCH 163/166] Clarify the work associated with tier 2 and tier 1 targets 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. --- text/0000-target-tier-policy.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 2ee3d11d901..d7febe26c85 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -47,8 +47,10 @@ Rust provides three tiers of target support: Adding a new tier 3 target imposes minimal requirements; we focus primarily on avoiding disruption to other ongoing Rust development. -Tier 2 and tier 1 targets place work on the Rust community as a whole, to avoid -breaking the target. Thus, these tiers require commensurate and ongoing efforts +Tier 2 and tier 1 targets place work on Rust project developers as a whole, to +avoid breaking the target. The broader Rust community may also feel more +inclined to support higher-tier targets in their crates (though they are not +obligated to do so). Thus, these tiers require commensurate and ongoing efforts from the maintainers of the target, to demonstrate value and to minimize any disruptions to ongoing Rust development. From 1979ced1797a3b44854ac19b7bb2d83e25cf4632 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 14 Apr 2021 11:11:36 -0700 Subject: [PATCH 164/166] Clarify use of issues to track requirements 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. --- text/0000-target-tier-policy.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index d7febe26c85..7fdca2be1ea 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -93,13 +93,13 @@ Rust project. Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. Before filing an issue or pull request (PR) to introduce or promote a target, -the target should already meet the corresponding tier requirements. (This does -not preclude a target's maintainers using issues to track requirements that -have not yet been met, as appropriate; however, before officially proposing the -introduction or promotion of a target, it should meet all of the necessary -requirements.) A target proposal is encouraged to quote the corresponding -requirements verbatim as part of explaining how the target meets those -requirements. +the target should already meet the corresponding tier requirements. This does +not preclude an existing target's maintainers using issues (on the Rust +repository or otherwise) to track requirements that have not yet been met, as +appropriate; however, before officially proposing the introduction or promotion +of a target, it should meet all of the necessary requirements. A target +proposal is encouraged to quote the corresponding requirements verbatim as part +of explaining how the target meets those requirements. All supported targets and their corresponding tiers ("tier 3", "tier 2", "tier 2 with host tools", "tier 1", or "tier 1 with host tools") will be documented From ac317718bb1b9ccaaa43c484ba1c3e5793d8c956 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Wed, 14 Apr 2021 11:14:08 -0700 Subject: [PATCH 165/166] Document that raising baselines should be widely communicated --- text/0000-target-tier-policy.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index 7fdca2be1ea..cd9e09f053a 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -613,7 +613,8 @@ planned and scheduled action.) Raising the baseline expectations of a tier 1 target (such as the minimum CPU features or OS version required) requires the approval of the compiler and -release teams, but does not necessarily require a full RFC. +release teams, and should be widely communicated as well, but does not +necessarily require a full RFC. ### Tier 1 with host tools From 7c1b640163ce0519d591a8896e30aa5405f79757 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Sun, 18 Apr 2021 11:16:52 -0700 Subject: [PATCH 166/166] Don't hardcode the path to one source file in tidy Just reference the tidy tool itself. --- text/0000-target-tier-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-target-tier-policy.md b/text/0000-target-tier-policy.md index cd9e09f053a..a9dca0df1fc 100644 --- a/text/0000-target-tier-policy.md +++ b/text/0000-target-tier-policy.md @@ -171,7 +171,7 @@ approved by the appropriate team for that shared code before acceptance. host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding - new license exceptions (as specified by `src/tools/tidy/src/deps.rs` in the + new license exceptions (as specified by the `tidy` tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be