SSS Hata Raporları

This article has been transferred to the http://wiki.opensuse.org/openSUSE:Bug_reporting_FAQ . Please use new location for your contributions. Don't create permanent links to the http://wiki.opensuse.org. It is temporary location and it will be switched back to http://en.opensuse.org after sufficient number of articles is there, or latest by July 12th, 2010. You can help us and speed up the process by participating in creation of a new wiki that will replace the current one. See Transition guidelines for more details.

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

This article describes how to use bugzilla at bugzilla.novell.com and list the frequently asked questions on bug reporting, and the resulting answers.

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 opensuse@opensuse.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. See Wishlist page to add those ideas.

---

General Bug Handling

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 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 your "prefs" are not changed, you will get informed via email about any changes.

If you are questioned or just feel need to comment any response please do not send email to the commenter address that comes in automatically generated mail from bugzilla. You should use 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 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 openSUSE 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 openSUSE x.y and still fails for openSUSE 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 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 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.

Please prefer 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 are usually more people working on one bug and this information should be accessible for all of them to ensure quick fix.

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.

What happens if I do not answer my bugs in state NEEDINFO?

A bug that is longer than one month in the state NEEDINFO might be closed as "Resolved: NORESPONSE" with a friendly message like "Requested information not provided for more than 4 weeks, closing 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 VERIFIED / CLOSED

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

[TBD]

---

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 Submitting Bug Reports

---

openSUSE Documentation

Report openSUSE documentation defects in Bugzilla (component: "Documentation") and for release products also add entries to Errata in the openSUSE 11.0 Documentation or Errata in the openSUSE 10.3 Documentation.

---

Beta Testing

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

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

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.