Bug Process

This page describes how the Toolchain Working Group handles reported bugs, the process that they go through, and the timings involved.

When to create a bug in bugs.linaro.org

Bugs should be created in bugs.linaro.org for issues in Linaro products. If we know that an issue is also present in an active branch of an open source project then it is not necessary to create a bugs.linaro.org bug and an upstream bug can be created instead.

Priorities

The Toolchain group uses a subset of the supplied severities:

critical

affects the overall usability of the product

normal

a bug that affects the product in certain situations

minor

a bug that affects the product very rarely, is cosmetic or has a good easy workaround

enhancement

feature request

Process for triaging Toolchain bugs in bugs.linaro.org

Bugs in the UNCONFIRMED state need to be triaged. The process of triage is to verify whether or not a bug is a real bug that applies to a Linaro toolchain product. The traige process should begin within one working week of the bug being opened. Any additional information you discover during the process of triage should be added to the bug log.

The first step in triaging a bug is to reproduce it. The bug should contain enough information: version number of Linaro toolchain and OS, command line flags, pre-processed source, hardware used etc. If the bug cannot be reproduced using the supplied information then the bug submitter should be requested to provide additional information, an example might be:

"Thanks for your report. Please could you provide the version of the Linaro toolchain with which you saw this issue?"

If the bug cannot be reproduced after 3 months without any response from the bug submitter then the the bug status should be changed to RESOLVED with resolution NON REPRODUCIBLE.

The bug remains in the UNCONFIRMED status until the issue can be reproduced, at which point the status can be updated to CONFIRMED, unless it has been already fixed in which case it can move straight to status RESOLVED resolution FIXED ideally with a note detailing which commit and which Linaro toolchain release fixed the issue. At this point if the Linaro project has an upstream bugzilla we should try to find a corresponding issue there or create one if none exists. A link to the upstream issue should be added to the bug log.

If the bug cannot be reproduced due to an error on the part of the bug submitter, for example the code showing the issue is not valid, then the bug status should be changed to RESOLVED with resolution INVALID.

The triage process may also involve changing the product or component of a bug or adjusting the severity if the existing value is not appropriate.

Process for fixing Toolchain bugs in bugs.linaro.org

Once a bug has been triaged work can begin on fixing it.

First make sure the bug is assigned to you and any corresponding upstream bug is also assigned to you.

If a project has an upstream bug tracker then all communication should be handled there. The bug in bugs.linaro.org should still be changed to the IN PROGRESS status with a note that development is being done in the upstream bug.

Once the bug has been fixed any upstream bug tracker should be updated and the bugs.linaro.org bug should be moved to the RESOLVED status with the resolution FIXED along with a note to specify which commit or commits fix the bug and the expected version of the Linaro toolchain which will contain the fix.

Bugs and JIRA

When working on bugs if a significant amount of time is to be spent then a JIRA card should be created to track the effort. Bugs should not be managed within JIRA itself however.

Feature requests, whether handled in upstream bug trackers or bugs.linaro.org should be supported by the normal Linaro REQ process.

WorkingGroups/ToolChain/BugProcess (last modified 2014-08-07 10:53:05)