If you did not migrate your account yet, visit https://idp-portal-info.suse.com/
openSUSE:Bug reporting FAQ
- 1 What kind of feedback do you want?
- 2 General Bug Handling
- 2.1 Which fields should be filled in initially? Which ones should I change and which ones not?
- 2.2 Will I get any feedback after reporting a bug?
- 2.3 Which fields should I change and which ones not?
- 2.4 What should I do if the current openSUSE version contains the same (or a similar) bug that exists already but was filed for an older version?
- 2.5 People got mad at me because I entered "Install openSUSE x.y-Beta-z" in Bugzilla's "how to reproduce" field. Why?
- 2.6 People were very unhappy because I only wrote "see subject" in the Bugzilla bug description - but my subject really explains it all! Isn't it pure nitpicking to insist on bug reporters repeating that in the description field?
- 2.7 Why is my report "XYZ doesn't work" not taken seriously?
- 3 Bug flag NEEDINFO
- 4 Bug Status RESOLVED
- 5 Bug Status VERIFIED
- 6 Bug Status WONTFIX
- 7 How to report a bug against ...
- 8 openSUSE Documentation
- 9 Beta Testing
What kind of feedback do you want?
We like to have both positive and negative feedback - and also ideas for improvement.
- Positive feedback means that we like to hear that a system was installed successfully and works, that certain areas have been tested and that those work. Please report this on the firstname.lastname@example.org mailinglist. Positive feedbacks are recorded in our testdb.
- For negative feedback which means any problems that are encountered, we use Bugzilla. Please file a separate bug report for each problem that you encounter. There are other areas in this FAQ that explain in detail how to file a bug report.
- Additionally, ideas for improvements, commonly called feature requests, are wanted. We collect those with openFATE, our feature database.
- Simon Tatham (1999). How to Report Bugs Effectively. https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
General Bug Handling
Which fields should be filled in initially? Which ones should I change and which ones not?
Note: not all bugs during the installation are YaST's fault, they could e.g. be kernel ones.
Use “all" if you think it is platform independent, otherwise state your platform.
People looking at the summary should understand what is going on.
- Bug description
Add all details about the bug. Note that you should not say "See summary" since the summary might get changed.
- How to Reproduce?
This is so important that it deserves an extra explanation in Q: 1.1.5
Choose the right severity. Mark it only as a “blocker" if it blocks your work on the product. The flag SHIP_STOPPER is available, if you think we should not ship with this bug unfixed in the product.
- The rest
You do not need to fill any of the other fields, the defaults are fine.
Will I get any feedback after reporting a bug?
Yes, if you do not change your Bugzilla Email Preferences to exclude receiving bug mail, you will get informed via email about any changes.
If you are questioned or just feel need to comment, please do not send email to the commenter address that comes in automatically generated mail from Bugzilla. You should use the Bugzilla web interface to communicate, because its the only way for relevant information to be accessible for everyone concerned.
Which fields should I change and which ones not?
As non-developer you should in general just add additional comments, or add yourself to the CC. If the bug has the NEEDINFO flag set, remember to check the "Clear the needinfo request" box after giving all the info.
What should I do if the current openSUSE version contains the same (or a similar) bug that exists already but was filed for an older version?
You have the option to change the version of the package and write in the comment something like "This bug was reported for openSUSE x.y and still fails for openSUSE u.v. I'm adjusting the version". If the bug has been set RESOLVED, you should reopen it.
People got mad at me because I entered "Install openSUSE x.y-Beta-z" in Bugzilla's "how to reproduce" field. Why?
Because this is completely useless information - redundant and not helpful in any way to reproduce a bug. We can tell a bug is about installation because you selected "Installation" from the Bugzilla component list, and we can tell what release you installed from the release list right next to that.
What we really need to know is what you did and how you did it - like "boot from CD1, select "Installation", select language "Klingon", leave the installation settings as they are, confirm installation, watch as your hard disk goes up in flames."
And no, this really, really isn't nitpicking - we have so many installation modes and so many installation paths that it takes ages to figure all that out from the log files. You have that information readily available, so please enter it at that field.
Of course, we don't need that level of detail when you are reporting a bug about a help text in one of the final hardware configuration dialogs (like printer, TV card, etc.) - but the steps to get to the place where the problem occurred we really need. We have so many dialogs that it isn't easy to figure out which one you mean and which path you followed.
People were very unhappy because I only wrote "see subject" in the Bugzilla bug description - but my subject really explains it all! Isn't it pure nitpicking to insist on bug reporters repeating that in the description field?
No, not at all.
Subjects get changed all the time. The problem you reported might only be the tip of an iceberg - the real problem might be at a completely different place, and then those knowing that place of course will change the subject accordingly. This in turn means that your original subject will get lost.
So it should be obvious enough that the subject is no place to store relevant information, and the problem that is being reported certainly is the single most important information in a bug report.
It is also simply bad style to dump all kinds of information in the subject and then only refer to the subject. This is just pure laziness. It costs you time once to do it properly, but everybody working with that bug has to search all over the place for the relevant information again and again.
In addition to that, a subject should be concise - but a bug description should be explanatory. Both requirements are contradictory.
Why is my report "XYZ doesn't work" not taken seriously?
We need more information to act. What version of XYZ does not work? In what context?
Bug flag NEEDINFO
What does that NEEDINFO bug flag mean, and how should this be handled?
NEEDINFO means that the bug owner (the person who is currently working on that bug) needs more information about that bug - usually from the bug reporter.
If you find a bug you reported has the NEEDINFO flag set, look for a question or a request to supply more information (such as logs etc.) in one of the last comments.
If this is the case, please answer that question or provide that information, respectively, and tick the checkbox "Clear the needinfo request" to have the NEEDINFO flag removed from this bug in the Bugzilla bug details page.
Please prefer the Bugzilla web interface for answering questions and attaching logs. Do not send this information by email unless you have serious reasons to do so. There is often more than one person working on one bug and this information should be accessible for all of them to ensure an appropriate fix.
Why is it important that I check the box to remove the NEEDINFO flag? Isn't that the bug owner's responsibility?
No, this is the responsibility of whoever answers the question that was asked or supplies the information that was requested.
Bug owners use NEEDINFO so they can more easily see what bugs they can actually work on (those set to CONFIRMED or IN_PROGRESS) and which ones are stuck because important information is missing.
Our maintainers receive so many generated mails that at peak times (like during a Beta phase) they cannot reasonably react to each one individually, so at a certain point they have to resort to bug lists - and then chances are that it is overlooked that some requested information is now available and work on a bug can resume.
So it is in the own interest of each bug reporter to remove the NEEDINFO flag after the questions are answered.
Of course, sometimes you can be lucky and the bug owner realizes that the requested information is now available and removes the NEEDINFO flag himself, but relying on luck is usually not a good tactic.
What happens if I do not answer my bugs with the NEEDINFO flag set?
A bug that is longer than one month with the NEEDINFO flag set might be resolved as NORESPONSE with a friendly message like "Requested information not provided for more than 4 weeks, resolving as NORESPONSE. Please reopen the bug once the information is provided."
As part of bug screening, other developers might also do this for bugs.
Bug Status RESOLVED
Should I mark a bug as RESOLVED when I see that the problem is solved in a new version or an update?
You may mark the bug as RESOLVED if it is noted in the changelog that the bug is fixed and the update has been released to openSUSE.
If upstream has fixed this but the update is not in openSUSE yet, you can comment on the bug if the developers are not aware of this already.
If a bug is filed under the "Security" component or has a title similar to the following:
- (CVE-2017-9872) VUL-0: CVE-2017-9872: lame: The III_dequantize_sample function in layer3.c in mpglib...
Please do NOT close these bugs manually, as these are handled by SUSE employees using internal software.
According to a SUSE employee:
- Once maintainer(s) are done with working on a particular bug, they should re-assign it to the email@example.com bug owner and we will process it from there on. We have some tracking & tooling attached to it, and closing the bugs without making sure that everything is fine on our end, might confuse the machinery ;-).
Bug Status VERIFIED
Should I mark a bug as VERIFIED when I see that someone has changed the state to RESOLVED after the problem is solved in a new version or with an update?
Bug Status WONTFIX
This section has been moved to Bug Status WONTFIX
How to report a bug against ...
For more information about how to report bugs for different components, as e.g. the Kernel, KDE or Yast, please follow openSUSE:Submitting bug reports
Report openSUSE documentation defects in Bugzilla (component: "Documentation").
I'd like to participate in testing betas for openSUSE. Whom shall I contact?
I'd like to participate in testing betas for other products like SLES or SLED. Whom shall I contact?
Not all these products have beta programs, but if they do have, they might be accessible via The Novell Beta Program.