Reporting Bugs
Having tried out OpenSolarisTM, 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! But before you create a new bug, first search for an existing bug that already covers your case, which is even easier; the developers appreciate not having to spend time closing duplicates. Type the error message you're hitting, or some keywords that might describe your problem, into the text box that's at the top and bottom of the Bugzilla pages, and then click the Find button; this searches against all open bug reports. For extra credit, click on the Search link and use the full search features to search more deeply, including against already-closed bugs. If you find a match against an open bug, add any additional information you can offer that might help in diagnosing or resolving the bug. You can also add yourself to the CC list to be notified of updates to the bug.
If you've tried a search or two and didn't find a match, then 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 | QA Watch Alias |
|---|---|---|
| desktop | Issues relating to the desktop environment, including GNOME, Firefox, and the X server. | qa-opensolaris-desktop@defect.opensolaris.org |
| device-utility | Issues relating to the detection of hardware devices using the Device Driver Utility | qa-ddu@defect.opensolaris.org |
| documentation | Issues relating to documentation | qa-opensolaris-documentation@defect.opensolaris.org |
| hardware | Issues relating to hardware support and drivers including sound, graphics and other peripherals. | qa-opensolaris-hardware@defect.opensolaris.org |
| i18n-l10n | Issues relating to the translation of software in OpenSolaris | qa-opensolaris-g11n@defect.opensolaris.org |
| install | Issues relating to the installation of OpenSolaris. | qa-opensolaris-install@defect.opensolaris.org |
| kernel | Issues relating to the kernel, and core operating system features. | qa-opensolaris-kernel@defect.opensolaris.org |
| livecd | Issues relating to the LiveCD capability of OpenSolaris. | qa-livecd@defect.opensolaris.org |
| networking | Issues relating to network configuration and connectivity. | qa-opensolaris-networking@defect.opensolaris.org |
| packaging | Issues relating to the network based package management system, IPS. | qa-opensolaris-packaging@defect.opensolaris.org |
| software | Issues relating to additional software on the single CD install, or that available on the IPS network package repository hosted at opensolaris.org. | qa-opensolaris-software@defect.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?
- "Severe Performance Problems" - ...and they occur when you do what?
- "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.
- "Installer crashes if launched from OpenSolaris Developer Preview LiveCD" - Explains what happens, and the context.