OpenSolaris

1. Project: Indiana
   1. Discussions
   2. Documentation
   3. Status
      1. Accessibility
         1. Do-It-Yourself Constructor Notes
      2. Derivative Distributions
      3. Familiarization
      4. Installation
      5. Laptop
      6. Package Management
   4. Leaders
   5. Observers
   6. Library
   7. Files
   8. CD Space Analysis (primary languages)
   9. CD Space Recommendations

Reporting Bugs

Having tried out OpenSolaris^TM 2008.05, you may have come across flaws in the software known as 'bugs'. Reporting bugs to the developers is the best way of providing feedback about your experiences, and making sure the flaws and frustrations you come across are fixed in the future. We use defect.opensolaris.org to act as that crucial interface between the developers and users. We very much appreciate you taking the time to help us improve the quality of our software.

Create an Account

If you wish to log a bug, you will need to create an account on defect.opensolaris.org. To create a new account, simply provide a valid email address. After entering the email address, you will receive an email to confirm the creation of your account. Once you have confirmed your account, you will be able to login and report a bug.

Reporting a bug

Reporting a bug is easy! Click on the Enter a new bug report link, then on the Distribution link, and then on the opensolaris product. You will notice you can choose a specific component on which to log a bug -

Component	Description
desktop	Issues relating to the desktop environment, including GNOME, Firefox, and the X server.
hardware	Issues relating to hardware support and drivers including sound, graphics and other peripherals.
install	Issues relating to the installation of OpenSolaris.
kernel	Issues relating to the kernel, and core operating system features.
livecd	Issues relating to the LiveCD capability of OpenSolaris.
networking	Issues relating to network configuration and connectivity.
packaging	Issues relating to the network based package management system, IPS.
software	Issues relating to additional software on the single CD install, or that available on the IPS network package repository hosted at opensolaris.org.

Once you have selected your component, fill in a Summary and Description of what the bug is and click on the Commit button. You may optionally want to set the Severity on the bug, giving us a rough idea of how severe you think the bug might be, along with anyone you would like to add to the Cc field. From time to time you may see activity on the bug as new information is added, along with the resolution of the bug either because there was an existing duplicate bug, or the bug was fixed!

Bug Reporting Tips

The best bug reports are those where the user has gone above and beyond the call of duty by providing as much information as they could regarding the bug. Where possible they have provided exact details of how to reproduce the bug, attached a stack trace or digital photo showing the bug where possible. Some good guidelines for writing effective bug reports are here.

General Tips for a Useful Bug Report

The following guidelines come courtesy of the GNOME project, for which we thank them. Use an explicit structure, so your bug reports are easy to skim. Bug fixers often need immediate access to specific sections of your bug. If your Bugzilla installation supports the Bugzilla Helper, use it.

Avoid cuteness if it costs clarity. At 3:00 AM, nobody will be laughing at your funny bug title when they can't remember how to find your bug.

One bug per report. Completely different people typically fix, verify, and prioritize different bugs. If you mix a handful of bugs into a single report, the right people probably won't discover your bugs in a timely fashion, or at all. Certain bugs are also more important than others. It's impossible to prioritize a bug report when it contains four different issues, all of differing importance.

No bug is too trivial to report. Unless you're reading the source code itself, you generally can't see many software bugs -- you'll see their visible manifestations. Severe software problems can manifest themselves in superficially trivial ways. File them anyway.

How and Why to Write Good Bug Summaries

You want to make a good first impression on the bug recipient. Just like a New York Times headline guides readers towards a relevant article from dozens of choices, will your bug summary suggest that your bug report is worth reading from dozens or hundreds of choices?

Conversely, a vague bug summary like "install problem" forces anyone reviewing installation bugs to waste time opening up your bug to determine whether it matters.

Your bug will often be searched by its summary. Just as you'd find web pages with Google by searching by keywords through intuition, so will other people locate your bugs. Descriptive bug summaries are naturally keyword-rich, and easier to find.

For example, you'll find a bug titled "Dragging icons from List View to gnome-terminal doesn't paste path" if you search on "List", "terminal", or "path". Those search keywords wouldn't have found a bug titled "Dragging icons doesn't paste".

Ask yourself, "Would someone understand my bug from just this summary?" If so, you've written a fine summary.

Bad bug titles:

1. "Can't install" - Why can't you install? What happens when you try to install?
2. "Severe Performance Problems" - ...and they occur when you do what?
3. "back button does not work" - Ever? At all?

Good bug titles:

1. "SUNWgnome-panel failed to upgrade from version 2.20.2 to 2.20.3" - Explains problem and the context.
2. "Installer crashes if launched from OpenSolaris Developer Preview LiveCD" - Explains what happens, and the context.