Description
Proposal: Begin enforcing Tier 2 target maintainer requirements
Note
This will definitely need a team FCP. I'm waiting until next Monday (2025-07-14) to leave time for feedback before proposing FCP.
Tier 2 Target Policy requires that (emphasis mine)
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.
- 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 documentation of the target.
We require target maintainers for Tier 2 targets because they are typically more niche, more difficult to build for and test against, and require target-specific expertise. Even triaging issues can be very difficult without having target maintainers to consult with, let alone fixing them. Making sure that these targets fairly reliably build (and remain functional) underpins the "Tier 2" target status, which itself conveys some degree of "promise" for users.
Historically, some Tier 2 targets were grandfathered-in (see rust-lang/rust#113739) as they predate the current Target Tier policy. rust-lang/rust#113739 was opened in July 2023 to begin working towards ensuring all Tier 2 targets have Platform Support docs (which are important both for maintainers to identify target maintainer contacts, and also users for platform baselines and build/test/run requirements) and dedicated target maintainers.
However, even to this day (2025-07-07), there are still some Tier 2 targets that lack Platform Support docs and/or target maintainers (see the survey below). I am thus proposing that we should start to enforce the Tier 2 target maintainers requirement with a grace period. After the grace period, Tier 2 targets that still fail to satisfy the target maintainer requirements may be demoted to Tier 3.
Each demotion decision will still be evaluated on their own merits.
This proposal exempts Tier 2 targets that have at least 1 target maintainer, since we at least have someone to consult with, and focuses on Tier 2 targets that don't have explicit target maintainers at all. Both Tier 1 and Tier 3 targets are beyond the scope of this proposal.
The proposed plan of action:
- Determine a suitable grace period.
- Create a blog post calling for maintainers for Tier 2 targets that lack sufficient target maintainers and/or Platform Support pages.
- Tier 2 targets that only have 1 maintainer will be mentioned too, but not as much of a priority.
- The intention is to eventually enforce the target policy, this is part of a very phased rollout to increase target policy compliance.
- After the end of the grace period, announce in a follow-up blog post that we will begin to demote Tier 2 targets that still fail to satisfy Tier 2 target maintainer requirements. Demotion decisions will be evaluated on their own merits for each target, following usual target demotion processes.
- As part of the very phased rollout, Tier 2 targets that still do not have any target maintainers will be first re-evaluated.
- Demoted targets may still be reproposed to be promoted to Tier 2, with the usual target promotion process, if they gain sufficient new target maintainers.
Context
- "Legacy" tier 2 targets have misplaced or absent maintainer docs rust#113739
- See: Tier 2 Targets Review #660
A Survey of Tier 2 Target Maintainers Status
This is a snapshot of the HackMD draft: https://hackmd.io/4goAKkfrTUGd1KkwGAhlQQ
Last revised: 2025-07-07.
Status of Tier 2 with host tools targets
Note: when a platform support page is absent, it is assumed that the target do not have any target maintainers.
Tier 2 with host tools targets with no platform support pages or explicit target maintainers
aarch64-unknown-linux-muslarm-unknown-linux-gnueabiarm-unknown-linux-gnueabihfarmv7-unknown-linux-gnueabihfi686-pc-windows-gnupowerpc-unknown-linux-gnupowerpc64-unknown-linux-gnux86_64-unknown-linux-musl
Tier 2 with host tools targets with only 1 explicit target maintainers
x86_64-unknown-netbsd- Note that there is a primary target maintainer who serves at point of contact, but there are fallback target maintainers, so this seems fine.
Special notes
- The platform support docs for
x86_64-unknown-netbsdis inconsistent. It's listed under Tier 2 with host tools, but its linked platform support page (https://doc.rust-lang.org/nightly/rustc/platform-support/netbsd.html) claims Tier 3 status.
Status of Tier 2 without host tools targets
Note: when a platform support page is absent, it is assumed that the target do not have any target maintainers.
Tier 2 without host tools targets with no platform support pages or explicit target maintainers
aarch64-unknown-noneaarch64-unknown-none-softfloatarm-unknown-linux-musleabiarm-unknown-linux-musleabihfarmv5te-unknown-linux-gnueabiarmv5te-unknown-linux-musleabiarmv7-unknown-linux-gnueabiarmv7-unknown-linux-musleabiarmv7-unknown-linux-musleabihfarmv7a-none-eabii586-unknown-linux-gnui586-unknown-linux-musli686-unknown-linux-muslriscv64gc-unknown-none-elfriscv64imac-unknown-none-elfsparc64-unknown-linux-gnuthumbv7neon-unknown-linux-gnueabihfx86_64-unknown-linux-gnux32
Tier 2 with host tools targets with only 1 explicit target maintainers
arm64ec-pc-windows-msvcarmebv7r-none-eabiarmebv7r-none-eabihfarmv7r-none-eabiwasm32-unknown-unknownwasm32-wasip1x86_64-unknown-redox
Mentors or Reviewers
Process
The main points of the Major Change Process are as follows:
- File an issue describing the proposal.
- A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.