QA/Bugzilla/Поля/Статус/RESOLVED

From The Document Foundation Wiki
< QA‎ | Bugzilla‎ | Fields‎ | Status‎ | RESOLVED
Jump to: navigation, search

Назначение этой страницы

Эта страница посвящена статусу ошибок RESOLVED в поле Status в нашей Bugzilla. Она объясняет и уточняет цели имеющихся множественных состояний статуса RESOLVED, а также описывает шаги, которые команда QA может / будет предпринимать при обращении к ошибкам со статусом RESOLVED.

Значения RESOLVED

Для статуса RESOLVED есть несколько под-статусов:

FIXED

Статус означает, что эта ошибка была исправлена конкретным коммитом в исходный код проекта. В поле Whiteboard должен быть один или более тэгов вида target:<LO version X.y.z>, каждый из которых означает версию/ветку LibreOffice, в которые будет включён этот коммит.

Примеры:

  • 'Blue 1' is set to the same color as 'Sky Blue 1' - tdf#86511
    • Whiteboard: target:4.5.0 target:4.4.0.0.beta2

Если вы не знаете, каким конкретно коммитом была исправлена ошибка -- используйте вместо статуса FIXED статусы RESOLVED WORKSFORME.

INVALID

Такой статус устанавливают, если что-то в этом отчете об ошибке недействительно или не вычисляется. Например, если кто-то пишет такой отчет, как в примере ниже, мы помечаем его, как INVALID:

 I am a walrus
 I am a walrus and I think everyone should know. The repro steps are eating fish.

Раньше мы использовали статус RESOLVED INVALID для различных семейств ошибок, включая ошибки, которые были в статусе NEEDINFO более полугода. Теперь у нас есть статус #INSUFFICIENTDATA, который лучше подходит для этих категорий ошибок.

WONTFIX

Это может быть и ошибка, однако мы не планируем исправлять её по различным причинам (которые часто детализируют в комментариях, когда устанавливают статус WONTFIX). Например:

  • A bug that doesn't affect any actual users

DUPLICATE

Эта ошибка -- дубликат уже имеющейся в системе

WORKSFORME

Сокращенно WORKSFORME часто пишут, как "WFM".

Кто-то из команды QA тестировал эту ошибку и не смог воспроизвести её, используя предоставленные шаги и/или тестовый документ.

Такое же окружение для воспроизведения ошибки

Если у вас имеется такое же окружение, как у автора ошибки (такая же операционная система, та же версия LibreOffice), то мы чувствуем себя намного увереннее в таком статусе ошибки, как WFM. Если у вас нет такого же окружения, (та же версия LO, но ошибка на Windows, а у вас -- macOS), посмотрите, есть кто-нибудь на канале QA/IRC, у кого есть такое же окружение и кто мог бы проверить ошибку и вас заодно.

Исправлено в новой версии

Если ошибка исправлена в разрабатываемой ветке master, но не в текущей ветке Fresh, или исправлена в ветке Fresh, но не исправлена в Still, то ошибка считается исправленной, и мы будем отмечать ошибку, как WFM.

Примеры:

  • tdf#74300 - Base:Database "Position and Size" box does not paint - it displays what's beneath it instead
  • tdf#79289 - FILEOPEN: DOCX shapes turn to frames and fill background not retained

Если мы знаем, какой коммит исправил ошибку, то хорошо бы попросить автора коммита (разработчика), если возможно бэкпортировать исправление. Если мы не знаем, каким коммитом исправлена ошибка, то нам нужно это выяснить. Мы можем добавить ключевое слово bibisectRequest и ввести в поле whiteboard backportRequest:. Это будет означать, что нам нужно сделать «обратный» бибисект (выяснить, когда ошибка была исправлена), а не когда ошибка была внесена в код.

Примеры whiteboard:

 backportRequest:4.2 backportRequest:4.3

Примечание: Прежде чем вы обратитесь к разработчику с просьбой о помощи, попробуйте выполнить Bibisect, чтобы отследить, какой коммит исправил ошибку. Это помогает разработчикам максимально эффективно работать в каждый день!

Как только ошибка будет исправлена ​​во всех активных ветках LibreOffice (либо с помощью бэкпортирования, либо с помощью ветвей, достигающих EOL), или если разработчик отклоняет запрос на бэкпортирование (комментируя ошибку), тег backportRequest:x.y может быть удален и заменен на backportDenied: X.y.

MOVED

Используется, когда в Bugzilla не место этому отчёту.

NOTABUG

Статус устанавливается, если "проблема", описанная автором ошибки, часть ожидаемого поведения LibreOffice. Например:

  • A function works as expected tdf#85643
  • Round-off errors that occur due to floating-point arithmetic on integer values - tdf#86174

NOTOURBUG

Устанавливается, когда проблема есть, но это не проблема в LibreOffice.

Примеры:

  • LibreOffice reads/write the file format correctly, but some other software does not tdf#81854
  • Excel has a longstanding date bug that they can't fix due to backwards-compatibility issues tdf#86996
  • There's a limitation with software outside our control tdf#85652 redmine#845

INSUFFICIENTDATA

Как рекомендовано ESC, этот статус был добавлен для включения ошибок, которые были брошены их авторами или не имеют достаточного количества данных для продолжения сортировки и исправления ошибок.

Примеры:

  • Пользователь не желает делиться приватным документом с "кем угодно", и мы не можем воспроизвести ошибку
  • Ошибка находилась в статусе NEEDINFO более 6 месяцев

Причины:

  • В настоящее время мы помечаем брошенные ошибки, как RESOLVED WORKSFORME или RESOLVED INVALID, но дополнительное значение статуса может помочь нам уточнить, почему ошибка была брошена.
  • Дополнительный статус должен позволить нам быть более дипломатичными с пользователями и избежать потенциально негативных эмоций от статусов INVALID или WORKSFORME на таких ошибках

Имена:

  • Было предложено несколько имен для этого статуса:
    • ABANDONED
    • INSUFFICIENT_DATA (Red Hat)
    • EXPIRED (Launchpad)
  • Подчеркивание между двумя словами INSUFFICIENT_DATA было удалено, чтобы соответствовать стилю существующих статусов RESOLVED в Bugzilla