Blocker status email SOP

This document describes the procedure for sending blocker status emails. The email is intended to provide a high-level overview of release-blocking bugs.

Timing/trigger

Send weekly beginning after the upcoming release branches from Rawhide. It is typically sent on Fridays, however this is not a hard requirement.

Procedures

For each accepted and proposed blocker in the BlockerBugs application for the relevant milestone,

  1. Add a line to the table in Friday’s Fedora Facts. See that SOP for formatting instructions.

  2. In the blocker_email.txt file,

    1. Add information in the bug-by-bug detail section

      1. First line: <#>. <component name> — <bug link> — <bug state>

      2. Second line: <bug title/summary>

      3. Third line: (blank)

      4. Subsequent lines: Include a brief summary of the behavior and key constraints. Include the following, if appropriate:

        1. Link to upstream bug or pull request

        2. Updates that contain a candidate or verified fix

    2. Add information in the action summary section

      1. First line: <#>. <component name> — <bug title/summary> — <bug state>

      2. Section line: ACTION: <action statement (see below)>

      3. Third line (if applicable): NEEDINFO: <person marked NEEDINFO in the bug>

When the information is fully collected, create the email message

  1. To: [email protected], [email protected]

  2. cc: (appropriate team mailing lists, if applicable)

  3. bcc: action-ed and needinfo-ed people (excluding upstream trackers)

  4. Open the body with a quick summary of schedule status. For example, indicate the current target date.

  5. Include the contents of the blocker_email.txt afterward

Action statements

Action statements generally take the form of "<person/group> to <action>." You can write them however you want, but most will look like one of the following:

  • When there’s an upstream bug: "Upstream to diagnose issue"

  • When there’s an upstream PR: "Upstream to merge <PR ID>"

  • When there’s no upstream report and no diagnosis: "Maintainers to diagnose issue"

  • When there’s a patch/PR or new upstream release: "Maintainers to create an update with <patch/PR or upstream release>"

  • When there’s an update with a candidate fix: "QA to verify <update ID>"

  • When the bug is in VERIFIED state: "(none)"

  • When there’s informating missing: " "<person> to provide <missing info>"

Tips

The following is general advice.

  • Don’t worry about getting too deep into the technical aspects. You’re not there to diagnose issues.

  • Update bugs if the state is inconsistent with reality. (e.g. if an upstream PR exists, set it to POST)

  • If you’re short on time, skip the bugs that seem likely to be rejected.

  • Remove the emails from the cc and bcc lines in the text file before committing changes.

Want to help? Learn how to contribute to Fedora Docs ›