Bug 报告 FAQ

Bugzilla

General Bug Handling

This document describes how to use bugzilla at bugzilla.novell.com.

Which fields should be filled in initially? Which one should I change and which one not?

• Component
  Note: not all bugs during the installation are YaST's fault, they could e.g. be kernel ones.
• Platform
  Use “all" if you think it is platform independent, otherwise state your platform.
• Summary
  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
• Severity
  Choose the right severity. Mark it only as a “blocker" 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 your “prefs" are not changed, you will get informed via email about any changes.

Which fields should I change and which one not?

As non-developer you should in general just add additional comments, or add yourself to the CC. If the bug is in state “NEEDINFO" remember to set it to “ASSIGNED" after giving all the info.
Que? There is a checkbox, below comment, that states something like "This comment provides the needed info" - shouldn't that be used preferably?

What should I do if the current SUSE Linux version contains the same (or a similar) bug that exists already but was filed for an older version?

I suggest to move the version of the package and write in the comment something like "This bug was reported for SUSE Linux x.y and still fails for SUSE Linux u.v. I'm adjusting the version". If the bug was closed before, you should reopen it.

People got mad at me because I entered "Install SUSE 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 ice berg - 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 reference 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.

Bug Status NEEDINFO

What does that NEEDINFO bug status 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 is set to NEEDINFO, 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 set the bug status to ASSIGNED - click on Accept bug (change status to ASSIGNED) in the Bugzilla bug details page.

Don't I become the bug owner when I change a bug's status away from NEEDINFO to ASSIGNED (with Accept bug (change status to ASSIGNED) in the Bugzilla bug details page)?

No, the bug owner remains the same, only the status changes. You can safely do that without fear that this bug will become your responsibility because of this.

Why is it important that I set a bug status away from NEEDINFO to ASSIGNED? 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 ASSIGNED, NEW, or REOPENED) and which ones are stuck because important information is missing - NEEDINFO bugs no longer appear in their to-do list of open bugs.

This is why it is important that the bug status is set away from NEEDINFO to some other status - the bug owner might overlook the mail Bugzilla sends automatically for comment added to a bug, and then this bug might remain in status NEEDINFO for an indefinite period of time.

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 status 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 change the bug status away from NEEDINFO 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 sets the bug status to ASSIGNED himself, but relying on luck is usually not a good tactic.

Please note that bugs which are assigned to the BNC-Screening-Team (mainly YaST- and X11-related problems) initially or during the process should not be set from NEEDINFO to ASSIGNED by the reporter or the person the information was requested from. This is because a change of this status almost always involves a reassignment which is done by this team. Changing this status might cause the specific bug to appear on the wrong listing and might therefore be not handled (reassigned) efficiently. Thank you for taking this into account.

Bug Status VERIFIED / CLOSED

Should I mark a bug as VERIFIED or CLOSE him when I see that the problem is solved in a new version or with the updates?

[TBD]

YaST

This section has been moved to Bugs/YaST

Kernel Bugs

This section has been moved to Bugs/Kernel

SUSE Linux Documentation

Report SUSE Linux documentation defects in Bugzilla (component: "Documentation") and for release products also add entries to Errata in the SUSE Linux 10.0 Documentation or Errata in the SUSE Linux 10.1 Documentation.

Beta Testing

I'd like to participate in testing betas for SUSE Linux. Whom shall I contact?

openSUSE is open. Just subscribe to the openSUSE Project Mailing Lists and report your Bugs like described in Submit a Bug.

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.

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 [1] Mailinglist. This positive feedback is 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. There are special pages Package Wishlist and Feature Wishlist to add those ideas.

What is betatestdb.suse.de?

Betatestdb is a tool to see which packages have been tested by beta testers and if the tests have been successfull or not. This allows us to receive not only negative feedback (something is broken) via Bugzilla but also positive feedback that the packages are working and the product is stable.

For a large number of packages there are detailed testcases which contain a description what to do - either a special feature or the whole software package. Please follow these instructions and enter the results in betatestdb.

Note: To have a better view onto the packages, we separated the packages into different areas.