Operations - Rust Forge (original) (raw)

Rust Forge

Operations

Here is a list of recurring tasks to support the compiler team and help keep things moving forward. 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. Keep in mind that contributors are the best resource of the project and we want to be mindful of their time.

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) has 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 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”. Check carefully, don’t be trigger-happy. Discussions and comments about this practice can be directed on Zulip.

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?