This is an extended version of the SUSE bugzilla document defining terms used in filing bug reports together with some examples relevant for openSUSE and SUSE Linux Enterprise products in SUSE's Bugzilla. There should be no discrepancy between these two documents but if they are, please mention it on the opensuse-testing mailing list.
The severity field describes the impact of a bug. And the reporter is free to set this up
- Prevents developers or testers from performing their jobs. Impacts the development process.
- (Documentation) Key documentation is missing for critical testing and review.
- Unable to login
- Unable to perform certification tests
- Unable to update system
- Crash, loss of data, corruption of data, severe memory leak.
- (Documentation) prescribes or doesn't warn against actions that cause data loss or corruption.
- 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 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.
- Prevents mandatory feature from working properly
- Feature regression from previous release
- Regular issue, some non-major loss of functionality under specific circumstances
- (Documentation) missing, misleading, inaccurate, or contradictory information in the documentation, but successful task completion is probable.
- Prevents important or desirable feature from working properly
- Issue that can be viewed as trivial (e.g. cosmetic, UI, easily documented).
- (Documentation) contains stylistic or formatting issues, but functionality is not hindered.
- String typo
The priority field describes the importance and order in which a bug should be fixed. In all of openSUSE Bugzilla products this field is utilized by the programmers/engineers to prioritize their work to be done.
Leap Packages inherited from SLE are handled differently, there the priority is should be set only by SLE Release Manager as part of daily triage and corresponds with the estimated impact on the product. This would be the case for all products in PUBLIC SUSE Linux Enterprise product family. Thus the following list document the definition of Priority from a SUSE Release Manager stand point.
P0 - CritSit
This priority is reserved for SUSE's L3 team (which is responsible for evaluating, analyzing and fixing software defects and coordinating the defect-resolution process). It is not used for defects associated with products in development. The highest priority of all.
P1 - Urgent
Generally product shipment blockers. Often enough this priority is used when it affect a key/core part of SLE that cannot be fixed after the product is released - i.e., like installer bug, crashing installation kernel and similar.
- Preventing system installation/boot/update/upgrade
- Graphical Environment or CLI freeze/crash
P2 - High
Use this priority for mandatory defects, enhancements, and work items. That is, for items that must be resolved in this release.
- Nautilus crashing while opening a file for all x86_64 installations
- Fingerprint support (mandatory feature) does not work with gnome-screensaver
- Package management system is not able to lock packages with regular expressions (but rug parity is needed)
- Important security issues
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 but deffer to the maintenance update, release-notes and documentation issues.
- Nautilus crashing while opening a file ssh for certain non-default configurations
- Fingerprint support (mandatory feature) does not work with sudo
- Package management system is does not display correct progress
- 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.
- Nautilus crashing while opening a file ssh for particular user with a provided backtrace
- Fingerprint support (mandatory feature) does not work with sudo for users with complex configurations
- Package management system does not show correct icon for enhancement updates
- Notifications do not have the correct icon sometimes
P5 - None
Indicates that a priority has not been assigned and prioritized. Untriaged by SLE Release Manager for all PUBLIC SUSE Linux Enterprise products.
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.
Setting priority in all of PUBLIC SUSE Linux Enterprise is strictly restricted to SLE Release Manager. If you do not agree with the values, please do not change them and instead add a comment stating why you disagree.
This works exactly the opposite for all Leap community maintained packages where Release Manager can suggest priority but respects individual priorities set by the bug owner. There Release Manager can adjust severity to reflect the impact on the openSUSE Leap distribution or use flags mentioned bellow.
Please fill this in correctly as follows:
- Customers are represented by: Customer, IS&T, and Consulting.
- The openSUSE community is represented by "community user".
- SUSE 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 <email@example.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.
PUBLIC product prefix
All SUSE Products with the PUBLIC prefix are set up to have new bugs opened as public by default unlike regular SLE products. This was created as part of an effort to provide more transparency to the community after Closing The Leap Gap. This is used by default by SUSE's openQA and should be the preferred option for all SUSE Engineering teams unless the bug contains confidential partner data. There is still an option to make comments or description private if necessary.