Jump to: navigation, search

Difference between revisions of "StarlingX/Defect Handling Process"

(→‎Key StarlingX Bug Queries)
Line 1: Line 1:
 
= StarlingX Bug/Defect Handling Process =
 
= StarlingX Bug/Defect Handling Process =
−
 
  
 
== General ==
 
== General ==
 
* StarlingX is using launchpad for tracking bugs: https://bugs.launchpad.net/starlingx
 
* StarlingX is using launchpad for tracking bugs: https://bugs.launchpad.net/starlingx
−
* Generally, StarlingX follows the openstack project team guidelines for bug management, documented [https://docs.openstack.org/project-team-guide/bugs.html here]
+
* Generally, StarlingX follows the openstack project team guidelines for bug management, documented [https://docs.openstack.org/project-team-guide/bugs.html here].
  
 
== StarlingX Bug Lifecycle / Process ==
 
== StarlingX Bug Lifecycle / Process ==
 
=== Bug Reporting ===
 
=== Bug Reporting ===
−
=== Bug Tags ===
+
* When reporting a new bug, the reporter needs to use [[StarlingX/BugTemplate|the StarlingX Bug Template]] to provide the required information to further investigate 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 Team Leads.
 +
* 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.
 +
* The sub-project team lead (or delegate) then triages the bug further and adds a release tag based on severity. 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 [[StarlingX/Tags_and_Prefixes|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.
  
 
== Key StarlingX Bug Queries ==
 
== Key StarlingX Bug Queries ==

Revision as of 22:14, 11 September 2018

StarlingX Bug/Defect Handling Process

General

StarlingX Bug Lifecycle / Process

Bug Reporting

  • When reporting a new bug, the reporter needs to use the StarlingX Bug Template to provide the required information to further investigate 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 Team Leads.
  • 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.
  • The sub-project team lead (or delegate) then triages the bug further and adds a release tag based on severity. 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.

Key StarlingX Bug Queries

References

Openstack Bugs Wiki

Retrieved from "https://wiki.openstack.org/w/index.php?title=StarlingX/Defect_Handling_Process&oldid=164669"