Operations

“Operations” is a part of the Compiler Team that takes care of organizational and maintenance work and in general help things moving forward. T-compiler ops lives on Zulip under #t-compiler/ops.

Here is a list of recurring tasks. Ideally run through this list every week. If there are blockers or doubts, after having acquired the right context, don’t hesitate to ping people around. Contributors are the best resource of the project (and we want to be mindful of their time) and are always helpful.

You can trigger a discussion about a specific topic, issue or pull request by opening a new topic on Zulip in #t-compiler or, if it needs consensus and more focus from the team, it can can be labeled I-compiler-nominated and will be discussed in a meeting (see section Meetings).

Issues hygiene

• Issue to be prioritized: see prioritization.
• P-high issues without assignee: ideally this category of issues should have an assignee (filter out those without a PR).In rare cases it’s fine if they don’t.
• MCP in FCP status, close seconded since more 10 days, ensure no open concerns
• Check open MCPs: MCP is a protocol to bring proposals to the compiler team attention. Ensure MCPs are moving towards one of these two outcome, being seconded or being closed for lack of seconding. When it’s clear that an MCP won’t be seconded or is abandoned, after about two or three months is ok to query its status and evaluate closing it. Otherwise try to get them unstuck.
• Issues needing a reproducible
• Issues and PRs that are going through FCP: check if the team need to check their box. These issues are in the weekly triage agenda.

Prioritization for T-compiler

Some useful filters when looking at regressions.

• Nightly regressions without priority
• Beta regressions without priority
• Stable regressions without priority
• Untriaged regressions without a priority

PRs hygiene

• Every PR should have a team assigned
  • PR without a team label
  • Waiting on author
  • Waiting on a review

Things to do a week before the release:

• No regression without priority: ensure they’ve been fixed and if not try to get the team attention.
• No beta regressions or stable regressions regressions without an owner, filter out those out without a PR.
• No beta regressions or stable regressions regressions work in progress, ideally they should all be merged.
• Ensure breaking changes (i.e. regressions agreed to be acceptable) have a corresponding issue tagged relnotes-tracking-issue, see list of release notes. T-release will then pick them up and add them to the release notes.

After the release

• Check carefully which regressions can be closed as “accepted”. Add a comment clarifying that the PR causing the regression is accepted as breaking change, example: “Closing since PR #123456 will be mentioned in the release notes”. Discussions and comments about this practice can be directed on Zulip.

Meetings

T-compiler has two kinds of meetings: triage and design meetings. Triage meetings happen weekly, there is a tool to generate 80% of the meeting’s agenda. Design meetings proposals are advanced on the T-compiler repository and scheduled during recurrent steering meetings (where the next design meetings are scheduled). Design meetings also need an agenda and a bit of work to summarize the topic and bring together documentation, invite relevant people and so on.

Rest of the world

These filters are for checking what’s happening in other teams

• List of open RFCs (all teams) waiting for the team to discuss or check the proposal, can anything be done to help moving them forward?