Rust developers regularly implement new targets in the Rust compiler,
and reviewers of pull requests for such new targets would like a clear,
consistent policy to cite for accepting or rejecting such targets.
Currently, individual reviewers do not know what overall policy to
apply, and whether to apply solely their own judgment or defer to a Rust
governance team.

Rust developers regularly ask how they can raise an existing target to
tier 2 (and in particular how they can make it available via rustup),
and occasionally ask what it would take to add a new tier 1 target. The
Rust project has no clear official policy for target tiers. People not
only don't know, they don't know who to ask or where to start.

This proposal documents an official policy for adding new (tier 3)
targets, and for raising targets to tier 2 (with rustup builds) or to
tier 1.

Based on discussions with the compiler team and representatives from
other teams.

Thanks to pietroalbini for suggesting "marker teams" in rust-lang/team,
and for elaborating on downsides of using GitHub team membership.

…!()`

Also explain a common case where this may come up.

…eams

… 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.

…tests

…brary

…team

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.

Add it to the introduction of the requirements, rather than listing it
as a "drawback".

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.

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.

"on call" could potentially have undue connotations of response time
expectations, analogous to having to wear a pager.

…elopment team"

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.

The level of maintenance required is much lower, but we should still
have a point of contact identified.

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.

Targets without an OS are not expected to implement `std`, for instance.

Inspired by issues regarding whether a new target must support stack
probes.

We don't want people thinking that adding a target is a one-off effort.

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.

We're trying to prevent messages that make a target's de-facto tier
higher, not prevent discussion about a target entirely.

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.

Introduce new sections for "tier 2 with host tools" and "tier 1 with
host tools".

In practice, this is a strong "should", not a hard "must".

…ments