- Feature Name: (N/A)
- Start Date: 2024-05-13
- 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

This RFC introduces a policy for including 3rd party projects in `rust-lang/rust` CI.

# Motivation
[motivation]: #motivation

We already have some 3rd party project in CI (e.g. Fuchsia), however we can't just add every project in existence to our ci, thus we need a policy to help us decide if a project can be included (and similarly if we should remove it from CI).

# Proposed policy
[guide-level-explanation]: #guide-level-explanation

To be included in `rust-lang/rust`'s CI a project needs to fulfill the following requirements:

- It must be open source
- There needs to be a document describing the projects, listing maintainers and other information (similar to target maintainers files)
- At least 3 maintainers
- Which can be pinged if the projects stops compiling in our CI, to help triage and debug the failure
- If maintainers do not respond within 10 days, the tests will be temporary disabled
- Documentation on how to build/test/debug locally
- Tailored at rustc developers
- Must include a way to set rustc flags
- `T-infra` sign-off on CI implementation
- Version of the project must be pinned (so upstream changes don't unexpectedly break CI) and be regularly updated by the project maintainers (so we don't test outdated code)

# Drawbacks
[drawbacks]: #drawbacks

Having a policy is always better than deciding based solely on vibes. However, having the policy might cause us to include many more projects to CI, slowing it down.

# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives

- Why is this design the best in the space of possible designs?
- What other designs have been considered and what is the rationale for not choosing them?
- What is the impact of not doing this?
- If this is a language proposal, could this be done in a library or macro instead? Does the proposed change make Rust code easier or harder to read, understand, and maintain?

# Prior art
[prior-art]: #prior-art

- [Target tier policy](https://rust-lang.github.io/rfcs/2803-target-tier-policy.html)

# Unresolved questions
[unresolved-questions]: #unresolved-questions

- Who is responsible for making decisions?
- `T-infra` is responsible for CI impl
- Is `T-compiler` responsible for general decision?
- What is the process to apply for inclusion of a project in CI?
- `T-compiler` MCP?
- Is 10 days the right deadline for maintainers to **respond**?
- Should we require the project to be "notable"? Who and how decides if a project is notable?
- What should this policy say about relience on unsatble features?

# Future possibilities
[future-possibilities]: #future-possibilities

None yet.