QA/Bugzilla/Fields/Status/RESOLVED/ru

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

This page is about the RESOLVED state of the Status Field in Bugzilla. It is dedicated to explaining and clarifying the purpose of the multiple RESOLVED states as well as describing the steps which QA can/will take in addressing RESOLVED bugs.

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

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

Примеры:
 * 'Blue 1' is set to the same color as 'Sky Blue 1' -
 * 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 более полугода. Теперь у нас есть статус, который лучше подходит для этих категорий ошибок.

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.

Примеры:
 * - Base:Database "Position and Size" box does not paint - it displays what's beneath it instead
 * - FILEOPEN: DOCX shapes turn to frames and fill background not retained

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

Примеры whiteboard: backportRequest:4.2 backportRequest:4.3 backportRequest:4.2 backportRequest:4.3

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

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

MOVED
Used, when Bugzilla is not the proper place for the report.

NOTABUG
Статус устанавливается, если "проблема", описанная автором ошибки, часть ожидаемого поведения LibreOffice. Например:
 * A function works as expected
 * Round-off errors that occur due to floating-point arithmetic on integer values -

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

Примеры:
 * LibreOffice reads/write the file format correctly, but some other software does not
 * Excel has a longstanding date bug that they can't fix due to backwards-compatibility issues
 * There's a limitation with software outside our control

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

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

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

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