How Bugs are Handled

Our main interface to deal with defects in the kernel graphics driver is Bugzilla at Freedesktop.org. We cover multiple products and components depending on where the issue is located. Our development and QA teams try to respond and handle reported issues as quickly as possible. We constantly assess if we have enough information to proceed on analysis and investigation, and might contact the bug reporter to get further details or qualify a fix if we don't have the right equipment or configuration linked to the issue.

You might notice that our stacks are evolving every day to add new features, new platform support, new fixes, and new performance improvements. Therefore, if we negligibly forget a bug, or a bug has no activity for several months, we will ping the bug reporter to either confirm that the issue is fixed with latest stack, or to ask for more information. In cases where we don't get any response from the reporter for one week, we might assume that the bug is not reproducible and close the bug. The bug reporter can reopen the bug if they still see it in the new stack and can provide some fresh data that can help us to solve the issue.

You can find more details about the current bug life cycle, freedesktop.org (FDO), the Bugzilla bug state workflow, and what different bug priority levels mean below.

Bug Life Cycle

FDO Bugzilla Bug State Workflow

When a bug is reported, it comes with some default values, and its status is NEW. Note that successful bisecting should be done before setting Status = ASSIGNED and Assignee = as it is assumed that the revert or fix will be done by this person with existing knowledge. When a bug's status is moved to ASSIGNED, that means that a developer is assigned to that bug. As soon as development is done on the bug (including any upstream fixes), the status moves to RESOLVED. Then QA and / or the bug reporter can confirm that the solution resolves the issue by appropriately updating the bug status.

Developers or QA might ask for additional information. In that case, we change the bug status to NEEDINFO. Once you provide the requested information, you should change the status of the bug to its previous value.

Bug Priority

Usually, priority is changed and updated by QA, but severity can be modified by anybody. The high-level descriptions below provide some information on what we mean and how we address issues based on priority. This information is intended to be an overall indication.

P1≈ Highest or (High + blocker): Resolution of the defect takes precedence over other defects and most other development activities. It is applied "most of the time" to Critical severity defects blocking development, internal validation, or external customer validation.

​For example: System hang, crash, general protection fault, severe security vulnerability, loss or data corruption, certification failure, factory lines down -> app failure impacting overall system behavior, no workaround currently available.

P2≈ High or (Medium + major + frequency > 50%): defects are intended to be resolved within one of the next two external releases. P2 is applied "most of the time" to High severity defects applying to functionality, features, and use cases currently being integrated and targeted for the next milestone release. Should not typically be shipped to customers, but can be documented if it is.

​For example: Defect causes severe degradation to an intended feature, functionality, or use case. Recovery may require a soft reboot. The issue can be documented, a workaround might be possible without significantly impacting users, development or testing can be continued.

P3≈ Medium: defects must have a planned timeframe for resolution. P3 is applied "most of the time" to Medium severity defects applying to functionality, features, and use cases currently being integrated and targeted for the next milestone release.

​For example: Product fails to meet its specifications or requirements for non-key features. Workaround exists and is easily implemented. Development and testing can be continued.

P4≈ Low or Lowest: Defect here may or may not have plans to be resolved.

​For example: Cosmetics defects. Can be shipped to customers without resolution

Priority: Default is P3 or medium. Regression bug is a P2 or high, and a blocker bug becomes a P1 or highest priority.

Severity: Default is normal. If bug can impact many platforms, it can be up to major. Hang bugs are up to critical, and blocker bug can up to blocker.

Project: Intel® Graphics for Linux*