Public Beta Program Guidelines

Bugzilla Guideline

Introduction and Principles

All of our community infrastructure, including Bugzilla, is subject to our Code of Conduct. Please review the SUSE Code of Conduct before contributing to make sure that you understand our expectations.

Bugzilla is the SUSE report management system and tool to keep track of defects (bugs) in its products. We have made a special setup of Bugzilla for reporting bugs in our Beta (pre-release) SUSE products by Public Beta members.

These are the key principles to have in mind when you want to report a bug on Bugzilla:

Search Bugzilla, to see whether your bug has already been reported
Be precise
Be clear—explain it so others can reproduce the bug
Include only one bug per report
No bug is too trivial to report—small bugs may hide big bugs
Clearly separate fact from speculation
Attach relevant information like supportconfig, log files, coredumps, etc

Community Account

To be able to create new Bugzilla report, you need to have a so called “Community Account” (formerly known as Bugzilla account), that will give you access to various openSUSE and SUSE web services, like SUSE Bugzilla, openSUSE Bugzilla, Open Build Service, openSUSE Forums, etc. The full list of web services can be found in our Identity Provider Portal.

To create a Community Account, please go to our IDP Portal.

Last but not least, if you have any question or issue with your Community Account, you should read our IDP Portal FAQ (at the bottom of the page).

Privacy and Sensitive Data

Important

By default, all bugs opened against a SUSE Beta Product are visible and accessible to any SUSE account (i.e Public, SUSE Employees and SUSE Partners).

This means that all Beta participants can:

List all bugs opened against SUSE Beta Products
See the description and comments of these bugs
Download and open any attachments of the bugs

Therefore if you would like to restrict your bug report to SUSE employees only, you need to open the “Advanced Fields” when you open your bug report, and check the following option: “This bug is only open to employees and contractors“.

If you any concern or question about your privacy and sensitive data, please contact us at beta-programs@suse.com

Reporting a New Bug in Detail

It is the responsibility of the beta tester to provide all relevant information for SUSE engineering to be able to reproduce and understand the problem. This includes things like a concise description of the problem, software and hardware configuration, log files, coredumps, trace files, etc. Most of the files needed will be gather by the supportconfig tool.

Method 1

Click directly on the following link:

Method 2

Choose “Enter a new bug“
Select the product in which you’ve found the bug:
- SUSE Linux Enterprise Server
- SUSE Linux Enterprise Desktop
- SUSE Linux Enterprise High Availability Extension
Select the beta version of the product (for instance):
- Beta SUSE Linux Enterprise Server 15 SPX
- Beta SUSE Linux Enterprise Desktop 15 SPX
- Beta SUSE Linux Enterprise High Availability 15 SPX
Fill out the form, with the following mandatory fields and information, described in the next section Fields, and leave the rest untouched.

Fields

Here is some help understanding the bug:

Component

In which sub-part of the software does it exist? This field is required. Click the word “Component” to see a description of each component. If none seems appropriate, look for a “General” component.

Version

Select the corresponding Beta, RC, or GMC version that the issue is detected or applies to. Please note that we might ask you to reproduce our defects in the latest version available.

Severity

By default the Severity is set to Normal. SUSE engineering reserve the right to change the severity of any bugs related to a beta product.

Severity 1 – Critical: Please do not use this! It’s only used for official released products where the products are inoperable in production or are mission critical to the business.
Severity 2 – Major: Important features are unavailable; the product is not installable or not bootable, etc.
Severity 3 – Normal: Default severity. In most cases this is the severity of choice. The product does not work as designed resulting in a loss of use.
Severity 4 – Minor: This may be a request for documentation, general information, typography, etc.
Severity 5 – Enhancement: product enhancement request.

Summary

How would you describe the bug in approximately 60 or fewer characters? A good summary report should quickly and uniquely identify a bug report. It should explain the problem, not your suggested solution.

Good: “Cancelling a File Copy dialog crashes File Manager”
Bad: “Software crashes”
Bad: “SLES should work with my server”

Description

The details of your problem report, including:

Overview: More detailed restatement of summary. Add as many details as possible.
Steps to Reproduce: Minimal, easy-to-follow steps that will trigger the bug. Include any special setup steps.
Actual Results: What the application did after performing the above steps.
Expected Results: What the application should have done if the bug was not present.

Attachment

If there is any doubt, please attach a supportconfig to your bug. The file size limit is 10240 KB.

If your coredumps or supportconfig is greater that 10240 KB, contact us at beta-programs@suse.com and we will provide another way to provide your bits.

Collecting System Information and Log

supportconfig

As stated in Reporting a New Bug:

It is the responsibility of the beta tester to provide all relevant information for SUSE Engineering to be able to reproduce and understand the problem. This includes things like a concise description of the problem, software and hardware configuration, log files, coredumps, trace files, etc.. Most of the files needed will be gathered by the supportconfig tool.

The supportconfig tool collects SUSE Linux Enterprise system information for troubleshooting.

Note: The following Documentations are drafts.

Note: Detailed system information and logs are collected and organized in a manner that helps reduce service request resolution times. Private system information can be disclosed when using this tool. If this is a concern, please prune private data from the log files. Several startup options are available to exclude more sensitive information. Refer to the supportconfig(8) man page to see these options.

The following procedure shows how to create a supportconfig archive:

Open a shell and become root.
Run supportconfig without any options. This gathers the default system information.
Wait for the tool to complete the operation.
Retrieve the supportconfig and attach it to the Bugzilla report.

The default archive location is /var/log, with the file name format being nts_HOST_DATE_TIME.tbz

Please note that by default supportconfig does not retrieve all log files and does not perform all verifications. Use the -A options (supportconfig -A) to do so; however, this might generate a supportconfig archive greater than the Bugzilla file size limit.

For more details on how to use supportconfig, click here.

Please note that in the SUSE Public Beta Program, you do not need to have a Service Request number to use supportconfig.

YaST Bug

If you are facing a YaST defect and want to report bug, it is always interesting to attach a supportconfig and we might require additional logs described at
https://en.opensuse.org/openSUSE:Report_a_YaST_bug

Installation, Boot, Login, Network and Data issues

Our documentation has a great chapter on how to gather information and specific log for Installation, Boot, Login, Network and Data Problems:

https://susedoc.github.io/doc-sle/main/single-html/SLES-administration/#cha-trouble

Mailing List Guideline

Introduction and Principle

We have a small number of mailing lists to discuss SUSE Beta products. They are used by the SUSE Release Team to announce new beta images and technical information, as well as for general or technical questions, feedback, or defect reports related to SUSE Beta products from our beta testers base. Putting it simply, our mailing lists are the main collaboration and communication channels between you and SUSE Engineering around SUSE Beta products.

Only subscribers can post on our mailing lists.

Please keep in mind that when you post to our SUSE Beta Mailing List, you send your message to a large group of people (SUSE and non-SUSE employees, beta participants) to give you some of their time and attention to download, read, and potentially reply to your message. It is simply polite to make sure your message is relevant to as many of the people receiving the message as possible.