Руководство по отслеживанию багов и работе с ними

В этом документе описывается стандартный процесс работы с новыми багами и ошибками в проектах UBports. (Его не следует путать с руководством по созданию баг-репорта.)

Где отслеживаются ошибки?

Основной системой отслеживания ошибок для Ubuntu Touch является проект ubports/development/ubuntu-touch GitLab project на GitLab. В этом проекте фиксируются все проблемы системного уровня Ubuntu Touch; он также служит отправной точкой для пользователей, желающих сообщить о возникших у них неполадках.

Тем временем в других проектах группы также включены системы отслеживания задач:

  • Проблемы, характерные для конкретных устройств, отслеживаются в рамках проектов для каждого устройства в группе ubports/porting.

  • Основные приложения, расположенные в ubports/development/apps, имеют собственный баг-трекер.

  • Сообщения о системных ошибках можно также подавать непосредственно для каждого компонента из раздела ubports/development/core, если понятно, какой именно компонент работает с ошибками.

GitLab позволяет просматривать задачи на уровне всей группы,, ссылаться на задачи из других проектов и переносить задачи между проектами, благодаря чему выбор конкретного проекта при создании задачи становится менее важным. Если задача, касающаяся конкретного порта или веб-сайта, попала в проект ubports/development/ubuntu-touch, её можно перенести в соответствующий проект.

Метки

Все запросы - даже закрытые - должны маркироваться для корректной работы системы глобальной фильтрации GitLab. Например, это все запросы, отмеченные как „Kind: enhancement“ в проектах ubports/development group. Обратитесь к справочным страницам GitLab для получения дополнительной информации о поиске и фильтрации.

В проектах UBports используются следующие метки. Поскольку запросы Merge Requests (MR) в GitLab используют тот же набор меток, некоторые из перечисленных ниже меток могут применяться и к ним.

План

Подумать также о том, чтобы составить документ, описывающий процесс работы с запросами merge requests.

  • Kind: описывается характер проблемы

    • Kind: bug: здесь описывается проблема, связанная с некорректной работой чего-либо.

    • Kind: enhancement: улучшение. Это запрос на добавление новой функции или описывается возможность улучшения.

    • Kind: maintenance: запрос технического или сервисного обслуживания.

    • Kind: FTBFS: здесь описывается проблема «Fails To Build From Source» (компиляция из исходного кода завершается неудачно, сокращение заимствовано из Debian).

    • Kind: process: эта задача служит для отслеживания определенного процесса. Например, процесса выпуска релиза Ubuntu Touch.

    • Kind: question - вопрос. Это обращение в службу поддержки или вопрос общего характера. Его следует адресовать на форумы.

  • Needs: описание действия, которое можно или необходимо выполнить

    • Needs: help from community: у сопровождающих проекта в данный момент нет ресурсов для решения этой проблемы, поэтому они хотели бы получить помощь от сообщества.

    • Needs: confirmation/more info: ошибка требует подтверждения или дополнительной информации от пользователей.

    • Needs: feedback from author (Требуется обратная связь от автора): используется для пометки запроса merge request, требующего ответа от автора после проведения проверки (review). Это отличается от метки Needs: confirmation/more info (Требуется подтверждение/дополнительная информация), предназначенной для использования с задачами (issues).

    • Needs: discussion: неясно, как решить эту проблему, поэтому необходимо дальнейшее обсуждение.

    • Needs: rebase: этот запрос необходимо перенести, но у сопровождающих нет прав на отправку изменений в исходную ветку.

  • Severity: насколько серьезна проблема.

    • Severity: critical: эта ошибка важная и должна блокировать выпуск релиза (определяемого соответствующим этапом разработки).

  • Area: эта проблема относится к определенной части Ubuntu Touch (например, HAL, промежуточное ПО, пользовательский интерфейс). Метки с этим префиксом могут создаваться по мере необходимости.

  • Topic: this issue is related to a certain topic of interest (e.g. VoLTE, contact backend migration). Labels of this prefix can also be created as appropriate.

  • Resolution: used when the issue is closed for other reason than the issue being fixed.

    • Resolution: unable to confirm: we are unable to reproduce the issue and not enough information is provided.

    • Resolution: not our bug: the issue is not an issue in Ubuntu Touch, but rather is an issue in a third-party software installed by the user.

    • Resolution: won’t fix: A bug it does not make sense to fix, since it will probably resolve itself, be too much work, isn’t fixable, or an underlying component will soon change.

    • Resolution: work as intended: The behavior described in the issue is the intended behavior of the software.

  • Backport to: <branch name>: used by the automation to automatically backport an MR to a stable release branches.

  • Miscellaneous labels

    • Good first issue: the report contains instructions or hints required to fix it. It is an excellent place for someone new to learn about the project by fixing a real issue.

    • Hotfix: This MR/issue classifies for being included/resolved as part of a point release of Ubuntu Touch

Примечание

If a repository tracking issues locally defines it’s own labels, they should be documented in the README.md.

Status

Status field is used to indicate the progress of the issue. We’ve defined the following statuses:

  • New: This is the status for a newly-opened issue. This indicates that this issue is untriaged; Developers and triagers are encouraged to triage issues, assigns kind and other labels, decide whether this issue warrants a milestone, etc. Alternatively, if an issue is a work item, a tracking issue, or something similar filed by developers, this status can be skipped.

  • Ready to be worked on: Indicates that this issue is triaged and can be worked on.

Примечание

This status replaces default «To do» status.

  • Blocked: Indicates that something else has to be solved outside of this issue before this issue can progress.

  • In progress: Indicates that a developer is actively working on the issue. The issue should be assigned to that developer.

  • Has MR: A non-draft MR exists that will fix this issue.

  • Done: The issue has been fixed in the main branch.

  • Duplicate: The issue is a duplicate. GitLab sets this status automatically when the issue is marked as a duplicate.

  • Won’t do: The issue is closed for other reason than the issue being fixed. It should have «Resolution: *» labels to explain the reason (see above).

Майлстоуны (контрольные точки проекта)

Milestones are used to define which release an issue targets. At a given time, up to 3 milestones are open:

  • A milestone for the upcoming stable release e.g. „Ubuntu Touch 24.04-1.1“.

  • A milestone for the in development major release e.g. „Ubuntu Touch 24.04-2.0“.

  • Once the in development release enters a stabilization phase, a milestone for the next major release (e.g. „Ubuntu Touch 24.04-3.0“) can be created.

Developers are encouraged to avoid assigning too many issues to a milestone; an overflowing milestone makes the milestone not as useful as it could be in tracking progress of a release.

Назначение работы разработчику

To make it transparent who’s working on an issue, the developer should be assigned. This also allows the use of GitLab’s global filtering as a type of TODO list.

Разработчикам желательно не копить много задач и постоянно обновлять их статусы.

GitLab issue board

We use GitLab’s issue boards to visualize progress of issues in each milestone. The boards are kanban boards, where each column corresponds to each defined status (new, ready to be worked on, blocked, in progress, has MR, done, duplicate, won’t do).

GitLab epic

We use GitLab’s epics to denote a topic which might span single or multiple milestones/releases. This helps organizing some long-term goals which are too large to implement at once.

How labels, milestone etc. are being used?

Think of labels, milestone, and other fields as tools a person can use to efficiently communicate with the reporter, other developers, and interested parties. They could be use in a few ways:

  • Because those fields show up in the issue list, it can give an at-a-glance info about the issue, helping developers to quickly understand the issue. For example, a developer could look at an issue on the list, notice that the issue has «needs discussion» label, and decide to jump in to give their 2 cents.

  • A field could be used to filter only interested issues. For example, a community member wanting to contribute into confirming issues can filter only issues with «needs confirmation» label and start jumping in.

  • A field could also be used to filter out uninteresting issues. For example, when a developer want to look for an issue to work on, one would want to filter out «Kind: process» label (used for e.g. tracking issue for a release).

Since we don’t always have someone to specifically triage issues and set those labels, developers are encouraged to set all those fields as they work on an issue. This will help comminicating what has been done on the issue, and also help summarizing the issue for quicker understanding.