СОП рассылки о состоянии блокирующих ошибок

В этом документе описывается процедура отправки электронных писем о состоянии блокирующих ошибок. Письмо предназначено для предоставления высокоуровневого обзора ошибок, блокирующих выпуск.

Время/триггер

Отправляйте еженедельно, начиная после того, как предстоящий выпуск ответвится от Rawhide. Обычно письмо отправляется по пятницам, однако это не жёсткое требование.

Процедуры

Для каждой принятой и предложенной блокирующей ошибки в приложении BlockerBugs для соответствующего этапа,

  1. Добавьте строку в таблицу в Friday’s Fedora Facts. Инструкции по форматированию см. в том СОП.

  2. В файле blocker_email.txt,

    1. Добавьте информацию в раздел подробностей по каждой ошибке

      1. Первая строка: <#>. <имя компонента> — <ссылка на ошибку> — <состояние ошибки>

      2. Вторая строка: <заголовок/сводка ошибки>

      3. Третья строка: (пустая)

      4. Последующие строки: включите краткое описание поведения и ключевые ограничения. Включите следующее, если уместно:

        1. Ссылка на ошибку upstream или запрос на включение

        2. Обновления, содержащие кандидата на исправление или проверенное исправление

    2. Добавьте информацию в раздел сводки действий

      1. Первая строка: <#>. <имя компонента> — <заголовок/сводка ошибки> — <состояние ошибки>

      2. Строка раздела: ACTION: <формулировка действия (см. ниже)>

      3. Третья строка (если применимо): NEEDINFO: <человек, отмеченный NEEDINFO в ошибке>

Когда информация полностью собрана, создайте сообщение электронной почты

  1. To: test@lists.fedoraproject.org, devel@lists.fedoraproject.org

  2. cc: (соответствующие списки рассылки команды, если применимо)

  3. bcc: люди, для которых указаны действия и needinfo (исключая трекеры upstream)

  4. Начните текст письма с краткой сводки состояния расписания. Например, укажите текущую целевую дату.

  5. Затем включите содержимое blocker_email.txt

Формулировки действий

Формулировки действий обычно имеют форму «<человек/группа> должны <действие>». Вы можете писать их как угодно, но большинство будет выглядеть как одна из следующих:

  • Когда есть ошибка upstream: «Upstream должны диагностировать проблему»

  • Когда есть PR upstream: «Upstream должны выполнить слияние <PR ID>»

  • Когда нет отчёта upstream и нет диагностики: «Сопровождающие должны диагностировать проблему»

  • Когда есть патч/PR или новый выпуск upstream: «Сопровождающие должны создать обновление с <патч/PR или выпуск upstream>»

  • Когда есть обновление с кандидатом на исправление: «QA должны проверить <ID обновления>»

  • Когда ошибка в состоянии VERIFIED: «(нет)»

  • Когда отсутствует информация: « »<человек> должны предоставить <отсутствующую информацию>»

Советы

Ниже приведены общие рекомендации.

  • Не беспокойтесь о слишком глубоком погружении в технические аспекты. Вы там не для того, чтобы диагностировать проблемы.

  • Обновляйте ошибки, если состояние не соответствует реальности. (например, если существует PR upstream, установите его в POST)

  • Если у вас мало времени, пропустите ошибки, которые, вероятно, будут отклонены.

  • Удалите адреса электронной почты из строк cc и bcc в текстовом файле перед фиксацией изменений.

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