Skip to content

Issue workflow

Jump to bottom Edit New page
Christian Bielert edited this page Aug 2, 2013 · 1 revision

As GitHub's issue tracker does not allow more detailed state regarding the status of issues, this wiki page describes how we use issue tags/labels to replicate this extra state.

Labels

The issue tracker has the following labels

  • Component Labels: assembler, compiler, linker, scripts, sdk
  • Issue Type Labels: bug, enhancement, question
  • Progress Labels: duplicate, fixed, inprogress, invalid, wontfix

Use of tags

When creating an issue, it should have a component label associated with it marking to which SDK component it is thought the issue relates to ( assembler, compiler and linker refer to e-gcc, e-as and e-ld respectively, scripts refers to the SDK build scripts and sdk refers to the SDK as a whole and all other components that do not yet have labels)

It should also have a type label associated with it, denoting whether the issue is a bug to be solved, an enhancement to be made in the future or a question regarding the SDK (though these should really be posted on the forums instead.)

Progress Labels

The state of the average issue follows this trend:

  • new (no label) -> in progress -> fixed -> closed

An issue first has no label whilst it is being investigated and details regarding the issue are being collected. It then has the label inprogress allocated to it when a fix for the issue is in progress (the need to separate these sates becomes clear when considering an enhancement). Once the issue is thought to have been resolved, it is then relabelled with fixed and the issue is finally closed once this fix has been verified.

There are three other states that a issue could be in that does not follow the above flow.

  • duplicate is used when there are two or more issues filed that describe the same issue. One is closed (generally that with less discussion), with the other being used for all future discussion regarding the issue.
  • invalid is used when for example a bug is filed that describes intended behaviour, it is not a bug.
  • wontfix is used when a bug/enhancement is of a low priority that it currently does not warrant being fixed at this time. The issue may be re-evaluated and resolved in the future.
Add a custom footer
Clone this wiki locally