Bugs/Definitions

This article is under review! The contents are currently being evaluated and edited by User:Jonathan_R. Others should not make major changes in the meantime. Thanks for the cooperation.

Bugs:
Submitting Bug Reports - Bug Reporting FAQ - Bugs Definitions - Testing

{{{1}}}

Bug Severities

The severity field describes the impact of a bug.

Blocker

• Prevents developers or testers from performing their jobs. Impacts the development process.
• (Documentation) Key documentation is missing for critical testing and review.

Examples:

• Unable to login
• Unable to perform certification tests
• Unable to update system

Critical

• Crash, loss of data, corruption of data, severe memory leak.
• (Documentation) prescribes or doesn't warn against actions that cause data loss or corruption.

Examples:

• Crash that is repeatable and evident to multiple users
• Memory leaks that lead to OOM errors during average use in one week or less

Major

• Major loss of function, as specified in the product requirements for this release, or existing in the current product.
• (Documentation) missing, misleading, inaccurate, or contradictory information to the degree that by following the documentation successful completion of fundamental tasks is unlikely.

Examples:

• Prevents mandatory feature from working properly
• Feature regression from previous release

Normal

• Non-major loss of function.
• (Documentation) missing, misleading, inaccurate, or contradictory information in the documentation, but successful task completion is probable.

Examples:

• Prevents important or desirable feature from working properly

Minor

• Issue that can be viewed as trivial (e.g. cosmetic, UI, easily documented).
• (Documentation) contains stylistic or formatting issues, but functionality is not hindered.

Examples

• String typo

Bug Priorities

The priority field describes the importance and order in which a bug should be fixed. This field is utilized by the programmers/engineers to prioritize their work to be done.

P0 - CritSit

This priority is reserved for Novell's L3 team. It is not used for defects associated with products in development.

P1 - Urgent

Use this priority for urgent issues

Examples:

• Blocker: Generally is a P1
• Critical: Nautilus crashing while opening a file for all x86_64 installations
• Major: Fingerprint support authenticates regardless of the fingerprint swipes
• Normal: Package management log does not get rotated (will get large fast)
• Minor: SLED is misspelled in bootsplash

P2 - High

Use this priority for mandatory defects, enhancements, and work items. That is, for items that must be resolved in this release.

Examples:

• Critical: Nautilus crashing while opening a file for all x86_64 installations over ssh
• Major: Fingerprint support (mandatory feature) does not work with gnome-screensaver
• Normal: Package management system is not able to lock packages with regular expressions (but rug parity is needed)
• Minor: Notification about potential security issue is obscured on screen

P3 - Medium

Use this priority for desirable defects, enhancements, and work items. That is, for items we would like to fix, but we won't hold shipment for them.

Examples:

• Critical: Nautilus crashing while opening a file ssh for certain non-default configurations
• Major: Fingerprint support (mandatory feature) does not work with sudo
• Normal: Package management system is does not display correct progress
• Minor: Notifications do not wrap text properly and can be cut off sometimes

P4 - Low

Use this priority for optional defects, enhancements, and work items. This priority is not as strong as desirable.

Examples:

• Critical: Nautilus crashing while opening a file ssh for particular user with a provided backtrace
• Major: Fingerprint support (mandatory feature) does not work with sudo for users with complex configurations
• Normal: Package management system does not show correct icon for enhancement updates
• Minor: Notifications do not have the correct icon sometimes

P5 - None

Indicates that a priority has not been assigned.

Setting and Changing Priorities and Severities

If you open a bugreport, please set the severity correctly. The engineer responsible for a report will reevaluate the severity and set the priority. Changing severity and priority is something that should only be done by the engineer's direct manager and the product owner - especially the project and product managers. If you do not agree with the values, please do not change them and instead add a comment stating why you disagree.

Found By

Please fill this in correctly as follows:

• Customers are represented by: Customer, Novell Technical Services, IS&T, and Consulting.
• The openSUSE community is represented by "community user".
• Novell partners use "Third party developer/partner".
• QA uses the attributes Component Test and System Test; engineering uses Developer.

Found in Version

Please specify the version of the product used when the bug was observed. Once correctly set, this should not be changed. It provides valuable historical information.

Fixed in Milestone

The Fixed in Milestone typically includes a set of version specific project milestones. This field will be set automatically by the build system.

Ship Stopper Bugs

If you find a bug that you consider a ship stopper, set the flag "SHIP_STOPPER" to "?" and add - for the openSUSE distribution - Stephan Kulow <coolo@novell.com> as Requestee. Coolo will decide whether this is a ship stopper and set the "+" (marking it as ship stopper) or "-" (marking it not as ship stopper) value of the flag.

Please do only set SHIP_STOPPER to "?" and let Coolo handle the rest.