QA/Bugzilla/Fields/Status/RESOLVED/ru

    From The Document Foundation Wiki
    < QA‎ | Bugzilla‎ | Fields‎ | Status
    This page is a translated version of the page QA/Bugzilla/Fields/Status/RESOLVED and the translation is 49% complete.
    Outdated translations are marked like this.

    TDF LibreOffice Document Liberation Project Блоги сообщества Weblate Nextcloud Redmine Ask LibreOffice Пожертвования

    Other languages:

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

    Эта страница посвящена статусу ошибок 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:<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.

    For automated gathering of statistics, it is better to let the bug fixer change the resolution to FIXED. Either give the developer time to do it or politely ask them to change it, if they did not do it in a timely manner. It is fine to change additional bugs discovered fixed by a commit to FIXED right away, if it is more fitting than closing as DUPLICATE.

    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

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

    Please don't use this value if the same person has reported the exact same issue twice, as this would skew our metrics. Instead, close the duplicate(s) as "INVALID".

    WORKSFORME

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

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

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

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

    The decision to close a bug as WFM without feedback from the original reporter or confirmers is done on a case by case basis. Normally it is good to give others some time to test. The age of the report and its last confirmation should be taken into consideration.

    The reason a bug is WFM in the same reproduction environment could be that the user profile was corrupt. Make sure to ask the bug reporter to test LibreOffice in Safe Mode and see if resetting the user profile (after backup) resolves their issue.

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

    Если ошибка исправлена в разрабатываемой ветке 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

     backportRequest:4.2 backportRequest:4.3
    Note pin.svg

    Обратите внимание:

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


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

    If the fixing commit has been identified, the report can be resolved as "FIXED", or "DUPLICATE" if that commit closes another report that was describing essentially the same issue.

    MOVED

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

    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
    Retrieved from "https://wiki.documentfoundation.org/index.php?title=QA/Bugzilla/Fields/Status/RESOLVED/ru&oldid=776077"