Meta: Require MCP and relevant team nominations for adding (ecosystem, custom codegen backend) testing jobs that would block PR/Merge CI and require documenting failure protocol

[jieyouxu]

Note: This is intended to be an approximation to cross-team MCPs¹.

I'm proposing a new rust-lang/rust policy (it's drafted as a compiler MCP but with multiple team nominations) that we require MCP and relevant team nominations for adding (ecosystem, custom codegen backend) testing jobs that would block PR/Merge CI and require documenting failure protocol.

Please let me know if nominated relevant teams have suggestions, concerns or other feedback.

There's no I-{team}-nominated labels for some teams, so I'll have to do it manually (sorry):

• cc @rust-lang/rustdoc
• cc @rust-lang/bootstrap
• cc @rust-lang/infra

Footnotes

1. https://rust-lang.zulipchat.com/#narrow/channel/486433-all-hands-2025/topic/Project-scope.20MCP ↩

[the8472]

We discussed this during a libs meeting. We're in favor of having an explicit process to be notified when such jobs are added.

We would also like that process to contain a step where it must outlined what such a project is depending on so we can better understand what we're getting into.
Are they using unstable features? Do they knowingly depend on implementation details? Do they plan to expand or shrink such dependencies at a later point?

The proposed policy doesn't seem to discuss non-blocking jobs. Is it expected that there'll be a trial period before it's made blocking?

[jieyouxu]

The proposed policy doesn't seem to discuss non-blocking jobs. Is it expected that there'll be a trial period before it's made blocking?

The reason the policy doesn't discuss non-blocking jobs is that I feel like it's less of a blocker than... blocking test jobs.

• For blocking test jobs, you can't cc/ping the relevant test job owners after PR/Merge CI if you feel like the test job failure is not worth blocking PR/Merge CI. The PR author must deal with the failure (themselves or need to wait for other contributors or test job owners to help) if they want the PR to be possible to merge.

However, I can appreciate that it's still concerning to see a failure message from a failed job even if it's post PR CI or post Merge CI.

Good points regarding the outline for asking the test job owners "what do you want from the test job and what do you depend on", I'll amend the MCP draft to include this request.

[the8472]

I asked about non-blocking jobs because the phrasing "adding blocking jobs" is unclear whether they're immediately added as blocking or whether there's a non-blocking period before that where we check how often it breaks.

[jieyouxu]

Ah. I have not considered a grace period (or rather, transition from non-blocking -> blocking). I think I'll add that as a question (does the test job owners want to add the test job as immediately-blocking, non-blocking first but transition to blocking after some time, or perma non-blocking) that the test job owner is requested to answer.

I'll probably need to reword this as all testing jobs then.

[jieyouxu]

Update: instead of changing the MCP issue description itself (which is a pain to review), I moved the policy draft to a Forge docs PR at rust-lang/rust-forge#813. You can also find the rendered draft at https://github.com/jieyouxu/rust-forge/blob/mcp-for-ecosystem-testing/src/compiler/proposals-and-stabilization/custom-test-jobs.md.

[jieyouxu]

@the8472 the current form of the policy lives at https://forge.rust-lang.org/compiler/proposals-and-stabilization/ecosystem-integration-tests.html. Let me know if I should renominate this current form for re-review by library team.