Triaging

From postmarketOS

This page explains the triage process for issues and merge requests. It's written for pmaports and pmbootstrap but also applies to other postmarketOS maintained repositories.

Issues

New issue

Initial status and type

New issues get statusreported and are also given one of:

  • typebug - the issue is a well defined bug report
  • typesupport - the issue is a question or support request, not a bug
  • typefeature - the issue describes a missing feature

Device category

If the issue affects devices, a device-category label for the highest affected device category is added.

  • device-categorymain - affects at least one device in the main category
  • device-categorycommunity - affects at least one device in the community category
  • device-categorytesting - affects at least one device in the testing category

For devices in main and community categories, we also have one issue label per device, for example device-nokia-n900. These get added as well.

Additional categories

Some topics are important enough they have their own categories so that people can monitor them specifically. These include:

  • a11y - Issues related to accessibility.
  • audio - Issues related to audio.
  • ci - Issues related to the continuous integration (CI) testing infrastructure.
  • security - Issues related to security.
  • systemd - Issues related to systemd.
  • Waydroid - Issues related to Waydroid.

Status change

During the lifetime of the issue, the status may change:

  • statusconfirmed - issue has been confirmed (bug reproduced or it has been agreed upon implementing a feature request)
  • statusneedmoreinfo - issue is blocked because the reporter needs to provide more information
  • statuswontfix - the bug report describes intended behaviour or for some reason we won't fix this
  • statusnotourbug - this issue describes a bug in an upstream project.
  • statusinvalid - this is not a valid issue
  • statusduplicate - this is a duplicate of an existing issue.
  • statusfixed - the issue has been fixed!

Upstream issue

If the issue reported is an upstream bug, it doesn't always make sense to close it immediately. If having a local issue to track it adds value, for example if this is a very important bug and we need to know when it is fixed in postmarketOS, statusnotourbug is applied but the issue is kept open. Once it's fixed upstream AND fixed in postmarketOS, the statusfixed gets applied and the issue gets closed.

On the other hand, if it it doesn't add value to keep the bug around in postmarketOS, it should be closed after applying statusnotourbug.

In any case, a link to the upstream issue should be added to the issue - preferably edited into the top post so it's immediately visible when reading the issue.

Merge Requests

Similarly to issues, MRs should be assigned type of either typefix or typefeature. As well as appropriate device and device-category.

status labels only necessary for MRs that are closed instead of merged, only statusinvalid makes sense here.

See also