StarlingX/Defect Handling Process
StarlingX Bug/Defect Handling Process
- 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.
StarlingX Bug Lifecycle / Process
- 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.
- Milestones - TBD; not setup in launchpad currently.
- 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: <bug-id> 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.
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.
Key StarlingX Bug Queries
- Open Bugs
- Fixed Bugs
- Unassigned Bugs
- Bugs Needing Triage
- These are new or untagged bugs. This query is used during bug screening.
- Bugs with no target release
- Bugs with Low importance may have no target release as they are considered not gating
- Release-Specific Bugs
- For a list of sub-project specific bugs, consult the sub-project wiki pages