Document compiler backport nomination/review process

[jieyouxu]

Tip

Part of a meta-effort to document our team policies and processes, cf. #all-hands-2025 > team processes and policies session.

As part of the async compiler backport experiment, I noticed we didn't really have any concrete docs on how compiler handles backport nominations and decisions (esp. the async process that we're experimenting with now, but also the sync process).

This PR intentionally leaves out specific approvals thresholds because those are still subject to experimentation.

r? @davidtwco (and @wesleywiser)
cc @apiraino (compiler-ops 😁)
cc @cuviper (since you raised the "it's hard (for release team) to determine when to know compiler has reached a backport decision" point with me :D)
cc @rust-lang/release

Rendered

[apiraino]

So, a few thoughts.

I appreciate your effort to explain the topic exhaustively but this feels ... quite a lot of text for what the backport workflow actually is. I would like to review it to see if we can cut some foliage.

Second point: I think it's a bit premature at this time to set in stone, with this level of detail, the number of votes to approve backports. Let's not make it look like it's a binary thing (approved or not). During triage meetings only people attending the meeting vote so it's random how many votes we can have.

So, yes, let's make some assumptions (n=3 or n=2) but let's be flexible. I'd say we let people evaluate (async) the backport but the beta-accepted is applied at the triage meeting. I first want to see if this new way of backport voting gets more interest.

I will post on Zulip that we are starting to run this experiment and ask T-compiler members to help with the voting.

[jieyouxu]

I appreciate your effort to explain the topic exhaustively but this feels ... quite a lot of text for what the backport workflow actually is. I would like to review it to see if we can cut some foliage.

Yes, if there's any way to cut how verbose it is (or idk add some TL;DR), please do leave suggestions!

Second point: I think it's a bit premature at this time to set in stone, with this level of detail, the number of votes to approve backports. Let's not make it look like it's a binary thing (approved or not). During triage meetings only people attending the meeting vote so it's random how many votes we can have.

So, yes, let's make some assumptions (n=3 or n=2) but let's be flexible. I'd say we let people evaluate (async) the backport but the beta-accepted is applied at the triage meeting. I first want to see if this new way of backport voting gets more interest.

Yeah we can leave off the concrete numbers. I only Picked Something™ because they were obvious gaps.

Re. the specific approvals, it was mostly because release found it hard to determine if sth was actually approved or not (for the async workflow). But this isn't a problem if we double-check during sync triage meetings anyway, and specifically adjust the backport-accepted labels!

[jieyouxu]

Attempt by @apiraino at rewording this to be easier to follow and less verbose: https://hackmd.io/LsbYjhqSRbmeE73ubWgO8w

Currently iterating on that since it's easier to co-edit than a forge PR...

[jieyouxu]

Changes since initial version:

• Dropped specific approval thresholds (subject to experimentation still).
• Adopted some revisions from the HackMD to make it less verbose.

[jieyouxu]

Since this doesn't really have any approval thresholds anymore, and is more of a process doc now,

r? @apiraino

[apiraino]

I really like this version :) If there aren't further comments I'd be in favor of merging

thanks @jieyouxu