Estado de bloqueados de correo-e SOP

Este documento describe el procedimiento para enviar correos electrónicos de estado de bloqueo. El objetivo del correo-e es proporcionar una descripción general de los defectos que bloquean la liberación.

Temporizador/disparador

Enviar semanalmente, comenzando después de la próxima versión de las ramas de Rawhide. Normalmente se envía los viernes, aunque no es un requisito obligatorio.

Procedimientos

Para cada bloqueador aceptado y propuesto en aplicación BlockerBugs para el hito relevante,

  1. Añada una línea para el tablero en Datos sobre Fedora del viernes. Consulte el SOP para obtener instrucciones de formato.

  2. En el archivo blocker_email.txt,

    1. Añade información en la sección detallada de bug-by-bug

      1. Primera línea: <#>. <nombre del componente> — <enlace del fallo (bicho)> — <estado del fallo (bicho)>

      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: test@lists.fedoraproject.org, devel@lists.fedoraproject.org

  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 ›