Jump to: navigation, search

StarlingX/Defect Handling Process

< StarlingX
Revision as of 20:20, 25 September 2018 by Ghada.khalil (talk | contribs) (Key StarlingX Bug Queries)

StarlingX Bug/Defect Handling Process

General

StarlingX Bug Lifecycle / Process

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.
  • 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, the developer sets the Status to In Progress.
  • 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
  • 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.
  • The Team Lead or Developer can also set a bug to Won't Fix or Invalid based on further investigation. Notes must be added to the bug explaining the rationale.

Recommended Launchpad Display

It is recommended to customize the display in Launchpad to display the following information:

  • Importance
  • Status
  • Number
  • Assignee
  • Tags

This will make the queries below more useful.

Key StarlingX Bug Queries

References

Openstack Bugs Wiki