StarlingX/Defect Handling Process

= StarlingX Bug/Defect Handling Process =

General

 * StarlingX is using launchpad for tracking bugs: https://bugs.launchpad.net/starlingx
 * Generally, StarlingX follows the openstack project team guidelines for bug management, documented here.

Bug Reporting

 * When reporting a new bug, please use the StarlingX Bug Template to help ensure that the team can quickly triage and fix the bug.
 * As a reporter, do not change the Status of the bug. Leave it as New. There is also no need to enter any tags. This will be done as part of the triage process.

Bug Triage / Tagging

 * The stx-bugs team (https://launchpad.net/~stx-bugs) is responsible for triagging, assigning and tagging StarlingX bugs. The team includes the StarlingX Project Leads and delegates.
 * One or more members of the stx-bugs team reviews the new bugs and adds the applicable sub-project tags. This allows each sub-project team to see their bug backlog.
 * Note: This is currently an offline process and can be done by any member of the stx-bugs team. For now, we have decided not to have an online meeting for review as the meeting frequency maybe a challenge.
 * The sub-project team lead (or delegate) then triages the bug further and adds a release tag based on severity and when they believe they can fix the bug. At this point, they also set the Bug Importance (if not already done) and the Status to Triaged.
 * If an issue is minor and is deemed not gating for the next release, a release tag is not added. In this case, the Bug Importance should be set to "Low" to indicate that it does not gate any release.
 * It is recommended that the team lead triaging the bug add a comment with the rationale
 * For more information on the StarlingX tags, see the Tags & Prefixes page

Bug Investigation / Fixing / Closure

 * It is the responsibility of each sub-project team to manage their bug backlog.
 * The Team Lead has the ability to assign bugs to members of the team. Team members can also assign bugs to themselves (but not to others)
 * When working on a bug, it is recommended that the developer sets the Status to In Progress.
 * By default, the reporter is subscribed to the bug and will receive email notifications when comments are added. You can use this to communicate with the reporter if you have questions or need clarification.
 * It is expected that the reporter responds by adding another comment to the bug in launchpad.
 * All bug fixes must be fixed in master first.
 * When a fix is available, the developer specifies the bug-id in their commit messages using Closes-Bug:  so that gerrit automatically marks the bug as "Fix Released" when the code is merged. See the the StarlingX code submission guidelines.
 * During an active release RC period (i.e prior to the official release), each sub-project team decides whether a reported bug gates the release as they are in the best position to articulate the impact. If gating, the bug must be tagged with the appropriate release tag. The developer is responsible for cherry picking the fix from the master branch to the release branch.
 * Similarly, the sub-project team decides if any bugs need to be cherry-picked to a released branch. Only critical/high impact issues will be cherry-picked.
 * A bug can also be marked as Invalid or Won't Fix based on further investigation. Notes must be added to the bug explaining the rationale. The bug should remain assigned to the developer who investigated the bug. Do not assign it back to the reporter. This makes it easier to find bugs you worked on.

Bug Verification

 * Launchpad does not have a distinction between "Fix Resolved" and "Fix Verified". Once code merges in master, the bug is automatically updated to "Fix Released" and considered Closed. This doesn't provide a way to query bugs that need to be explicitly retested by the reporter
 * An optional tag (stx.retestneeded) will be used to track bugs that need explicit verification. The tag is added by the screener at the time the bug is triaged (or the reporter at the time the bug is created)
 * Once the bug is verified by the reporter/tester, a note is added to the bug and the label is removed by the tester.

Recommended Launchpad Display
It is recommended to customize the display in Launchpad to display the following information: This will make the queries below more useful.
 * Importance
 * Status
 * Number
 * Assignee
 * Tags

Key StarlingX Bug Queries

 * All Bugs
 * Open Bugs
 * Fixed Bugs
 * Unassigned Bugs
 * Help Wanted Bugs
 * Bugs Needing Triage
 * These are new or untagged bugs. This query is used for bug screening.
 * Bugs with no target release
 * Bugs with Low importance may have no target release as they are considered not gating
 * Undecided Bugs
 * This is another way to see bugs that are not screened. Some may have already been fixed
 * Incomplete Bugs
 * Release-Specific Bugs
 * stx.1.0 - All Bugs
 * stx.1.0 - Open Bugs
 * stx.2.0 - All Bugs
 * stx.2.0 - Open Bugs
 * stx.3.0 - All Bugs
 * stx.3.0 - Open Bugs
 * stx.4.0 - All Bugs
 * stx.4.0 - Open Bugs
 * stx.5.0 - All Bugs
 * stx.5.0 - Open Bugs
 * stx.6.0 - All Bugs
 * stx.6.0 - Open Bugs
 * stx.7.0 - All Bugs
 * stx.7.0 - Open Bugs
 * stx.8.0 - All Bugs
 * stx.8.0 - Open Bugs
 * stx.9.0 - All Bugs
 * stx.9.0 - Open Bugs


 * For a list of sub-project specific bugs, consult the sub-project wiki pages