Jump to content

Triaging

From postmarketOS Wiki
Revision as of 22:17, 16 October 2022 by Caleb (talk | contribs)

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.


🚧 This page is a work-in-progress. Some information contained within may be inaccurate or incomplete.
In particular: Missing issue lifespan and MRs

Issues

New issues get the statusreported label 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

If the issue affects devices, the label for the affected device[s] are added, as well as a device-category label for the highest priority device. e.g. if it affects a main and community device, the device-categorymain label is added.

Once the issue has been confirmed (bug reproduced, someone agrees to implement the missing feature), the statusreported label is replaced with the statusconfirmed one. If the issue is blocked because the reporter needs to provide more information, the statusneedsmoreinfo is added.

At this point, the issue is "in progress", and updated as needed.

Once some conclusion has been reached, one of the resolution labels can be applied:

  • resolutionwontfix - the bug report describes intended behaviour or for some reason we won't fix this
  • resolutionnotourbug - this issue describes a bug in an upstream project.
  • resolutioninvalid - this is not a valid issue
  • resolutionduplicate - this is a duplicate of an existing issue.
  • resolutionfixed - the issue has been fixed!
  • resolutionclosed - the issue has otherwise been resolved and doesn't need to be open anymore.

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 also makes sense, the resolutionnotourbug label is applied but the issue is kept open. Once it's fixed upstream AND fixed in postmarketOS, the resolutionfixed can be applied and the issue closed.

Merge Requests

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

resolution labels are only necessary for MRs that are closed instead of merged, only the resolutionclosed and resolutioninvalid labels make sense here.