Tizen 3.0 Bug Tracking

From Tizen Wiki
Jump to: navigation, search

Purpose of this document

This document describes the Tizen 3.0 Bug Tracking process.

Tizen 3.0 Bug Tracking in TC JIRA project

  • Tizen 3.0 consists of a common base and profile specific additions (IVI, Mobile and other forthcoming profiles). For more details about the common base, please check Common wiki
  • Tizen 3.0 TC JIRA project is created for all Tizen 3.0 bug and feature tracking. This will help work with one data base going forward. Profile bugs are also tracked in this project with specific components. Take Tizen IVI as an example, bugs for all IVI specific components are tracked in "Automotive/xxx" JIRA components.
  • Tizen Feature (PTF) and Tizen IVI (TIVI) JIRA projects are obsolete.

Configuration of TC project


JIRA Field Usage
Affects Version/s Milestone release in which the problem is found. Valide Affects Version for common: 3.0 Common 2014.Q2, etc. Valide Affects Version for IVI: 3.0 IVI M3, etc.
Attachment Attachment to help describe the issue or share information with others.
Assignee The engineer who is working on fixing the issue.
Component/s The domain where the issue belongs.
Defect Classification Defines what type of issue this is.
Description Details of this bug, including reproduce steps, expected result, actual result and rough analysis from reporter usually.
Environment More information about the test environment, can be hardware or software environment.
Fix Version In which version the bug is really fixed.
Labels User can add labels to do advantage filtering and bug management. No permission control for this field.
Platform/s Hardware platforms for this project. Use to tell which platform was used to find this bug.
Priority Hint how urgency the bug should be fixed. Valid values are: P1, P2, P3, P4, and Undecided. This is a controlled field, only people in "Triage Group" can set this field, but it's visible to all once it's set.
Profile/s Which profile this bug belongs to. The valid values are: Common, IVI, Smartphone and Emulator.
QA contact QA owner who should follow up with developer and verify this bug finally.
Reporter who file this ticket.
Reproducibility The probability of this bug. Valid values are: Always (100%), Often (50%~99%), Sporadic (21%~49%), Very Sporadic (<20%).
Security Level Who can see this issue. Valid values are: Locked, Declassified and None.
Severity From project impact perspective, defines how sever this bug is. Valid values are: Critical, Major, Normal, Minor and Undecided.
Snapshot ID The build ID of the image for firstly find the issue.
Summary Concise description of this bug, the title of this bug.
Target Date The target date to fix this issue.


  • Bold means mandatory fields, the bug reporter is expected to provide necessary information for a bug.
  • Affects Version/s means in which version this bug was found and which versions it impacts. After a milestone released, the open bugs will be revisited, and add new version in Affects Version if the bug also exists in it.

Controlled Field

  • Priority: Only people in "Triage group" can set this field, but it's visible to all once it's set. People in "Triage group" are PM, planner, developer representative, QA representative.


TC workflow.png 400

Main stream

  • New: The Reporter enters a new issue, including title, description, steps to reproduce, environment, and severity. Jira automatically sets Status to New and Assignee set to component leader .
  • New -> Assigned: Triage team reviews the issue, confirming Severity and Component and ensuring title, description, steps to reproduce and environment are complete. The Triage team sets Priority and optionally Target Date, and sets the status to Assigned. The Component Lead evaluates priority and delegate as necessary. Assign to developer .
  • Assigned -> In Progress: When the Developer begins actively working on the issue, they set Status to In Progress and set Estimated Delivery date. Assignee is developer .
  • In Progress-> Resolved(Fixed): When the Developer has a fix for the issue submitted to Gerrit, they set the status to Resolved. Assignee is developer .
  • Resolved -> Released: Release Engineering integrates the fix into a build and sets Status to Released. Assignee is developer .
  • Released -> Closed: QA/reporter tests the fix. If verified, QA sets Status to Closed and Resolution to Fixed. If not verified, QA sets status to Assigned. Assignee is developer .

Implicit path

  • New -> Resolved (Invalid/Duplicate): Triage team will resolve obvious Invalid and Duplicate bugs, set Status to Resolved and Resolution to Duplicate, won't fix or Invalid. Assignee keep unchanged component leader . QA will help to check if it's duplicate or invid bug on target device and close the bug if it's verified.
  • New -> Resolved (Won't fix): Developer might change the bug to Won't fix directly, the assignee should be changed to project manager .
  • Assigned -> New: Developer think triage result is not acceptable and need to be triaged again. Assign to component leader .
  • In Progress -> Assigned -> New: Developer find the bug need to be triaged again during bug fixing. (That's not recommend, but may happen in reality) Assign to component leader .
  • In Progress -> Resolved(Invalid/Wontfix/Duplicate/CantReproduced): Only when the Developer will not fix the issue, assign it to the Product Manager and set Status to Resolved and Resolution to Won't Fix. Assign to project manager . For other resolution, keep the assignee as it was. QA take the responsibility to verify Invalid, Duplicate and Can'tReproduced bugs.
  • Resolved (Invalid/Wontfix/Duplicate/CantReproduced) -> Closed: For Wontfix bugs, project manager close this bug if agree with the solution. Assignee is project manager . Other bugs will be verified by QA.
  • Released -> Assigned: QA/reporter think the bug still exist and developer need to fix it again. Assignee is developer .

Bug verification process

Bug found in Common image

  • Reporter: Set the profile as "Common"
  • Common Release Engineer: Set the bug status to be "Released" after the patch is integrated in common.
  • Common Tester: Verify the bug, either close it or open it to "Assigned" status based on test result.

Bug found in Profile image (e.g. IVI)

  • Reporter: Search if there is similar bug already reported. If there is a common bug, set the profile of the bug to be "Common, IVI". If there is no such bug, report a new bug and set the profile as "Common, IVI"
  • Developer: Mark the bug as "Resolved" once the patch is merged into git and "gbs submit" is triggered.
  • Common Release Engineer: Set the bug status to be "Released" after the patch is integrated in common.
  • Profile Release Engineer: Add comments once the patch is integrated to profile image.
  • Profile QA: Verify the bug with profile image, close the bug if it's fixed, or keep it as "Released" status and add comments for further check by profile release engineer. It's an integration issue with high probability in this case.

Bug triage process

  • Bug Triage is a process to
    • Ensure bugs are set with proper Priority/Severity
    • Ensure bug is reported with complete information for people to understand what the issue is
    • Resolve Invalid and Duplicate bugs.
    • Ensure enough log and debug info are provided for further diagnose to fix the bugs
    • Isolate bugs to components with 80% confidence
    • After a bug is triggered, the bug status should be Assigned, or Closed with Duplicate/Invalid resolution.
  • Bug Triage Team
    • A team work on bug triage, is expected to be comprised of QA rep(s), developer rep(s) as mandatory team members, and release engineer rep(s).
    • Team members need to be equipped with required expertise of the verticals or key domains, and MUST committed to the triage work.
  • Tizen IVI Bug Triage
    • For Tizen IVI project, triage team members includes Mikko(Architect), Dominique(Architect), Matti-Pekka(Feature PM), Bingwei(Feature PM), Francisco(Crosswalk PM), John Ji(SDK), Ed(Release Engineer), Cathy(QA rep.), Xiaolei(QA rep.).
    • QA initiate the daily triage and send proposal to triage team members, CC Mark(PM) and bug owners in this triage cycle. Feature PM review the triage proposal and drive the local scrub. QA will set the bugs status based on the feedback collected in 24 hours. Silence means agree to the proposal.
    • Controversial bugs will be discussed in SXT meeting.
    • To change the priority of an existed bug, pls. send mail to all triage team members. The decision will be made by triage team and follow the 24 hours rule as above.
  • Tizen Common Bug Triage for non-IVI bugs
    • Tizen Common team drive this to ensure the bugs are informative and assigned to proper person with proper priority timely.