SeaMonkey/Bugzilla-FAQ
 | ||
| Resources | ||
|---|---|---|
| SeaMonkey Homepage | ||
| FAQ / Help | ||
| Goals | ||
| Organization | ||
| QA | ||
| Supporters | ||
| Add-ons | ||
| Localization | ||
| Reasons | ||
| Branding | ||
| Release History | ||
| Tasks & Projects | ||
| ||
| Discussion | ||
| Suiterunner |
Here you find suggestions how to use Bugzilla for several questions without an answer in Mozilla Bug writing guidelines.
Contents
Before you start
- What issues are worth to be reported at Bugzilla?
- Anything wrong (or needing improvement) what can't be fixed immediately by user who observed the problem. Don't be shy, but consider that every report should be created with care according to Mozilla Bug writing Guidelines
General
How to unsubscribe from Bugzilla
Mostly the goal is to stop receipt of automated Bugzilla Messages. Users can do that without help:
- Open any Bugzilla page in your browser (by clicking on Bugzilla hyperlink in an e-mail you got from Bugzilla system)
- log in
- in heading area (Home - New - ...) click Preferences
- on Preferences page click Email Preferences' (location of this hypelink might depend on selected Skin for Bugzilla User Interface
- Click button Disable all Bugmail
- Click button Save Changes
Ready!
- Additional help you can find in Bugzilla Documentation
- If you can no longer login because you forgot your user data, you may ask a Bugzilla expert from SeaMonkey/Supporters.
If you want to unsubscribe completely from Bugzilla you will need an administrator's help via SeaMonkey/Supporters
Bug Report Details
How to read User Agent string information
Menu 'Help → about SeaMonkey' shows something like
- User-Agent: Mozilla/5.0 ( Windows NT 6.1 ; WOW64 ; rv:41.0 ) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38 Build identifier: 20150923195647
You can find some explication on MDN, hacks.mozilla.org and useragentstring.com (will analyze your user agent string).
Some more details:
- Mozilla/5.0 : Mozilla token
- Windows NT 6.1 : Platform identifier shows on what operating system that SeaMonkey version is used.
- Windows explained at Wikipedia
- WOW64 : operating system and SeaMonkey details:
- rv:41.0 : Gecko rendering engine version
- Gecko/20100101 : used to indicate the build date, but was considered a major source for browser fingerprinting; replaced by a constant dummy date since, it was retained for compatibility reasons.
- Firefox/41.0 : Firefox version what is basis of this SeaMonkey (browser) version
- SeaMonkey/2.38 : SeaMonkey version
- Build identifier: 20150923195647 : Unique timestamp of the build, not exposed in the user-agent string
How to use attached sample documents for multiple Bug Reports
It is not necessary and not useful to attach the same document in multiple bug reports again and again. You can simply create a link with the text "attachment 12345 from Bug 6789" in the comment text or report text. So you get a link to download the attachment easily and additionally you contribute information in what Bug report other interesting information concerning the document can be found. You find the attachment number by mouseover at the link in the original bug as the screenshot shows. Or you can copy / paste that info from the Bugzilla Attachment Details Info page. It's important to know at what Bug the attachment has been submitted, the Comments often contain important additional information.
The advantage compared to a copy is that everybody knows that the sample document in the new document is identical (the same) as in the other bug where the attachment has been added; so it is much more easy to compare results.
Bugzilla fields
Version
Should show the earliest (SeaMonkey) version with the reported problem. Together with Target Milestone, this field marks the range of (SeaMonkey) versions with the reported problem. This range-information is important for several useful Bugzilla-Queries, for example
- Decision whether an observed problem already has been reported.
- If a bug report is concerning a problem with similar symptoms, but Version or Target Milestone do not match, the observed problem can not have the same roots as the problem of the other bug report. Example: You observe that in Browser background pictures are not shown and you find a possible DUPlicate in a Bugzilla, you should compare Version and Target Milestone of that Bug with your observations. If the problem you observe started with the same SeaMonkey version as indicated in that Bug report, but that problem has become fixed for a SeaMonkey 2 Versions before yours, your observations are concerning a different problem, or the Fix for the other Bug is incomplete concerning the aspect causing the problem you observe.
Target Milestone
- For RESOLVED - FIXED: should show the earliest SeaMonkey version for what the bug has been fixed (known fix). Target information can be used in queries much more effected than the Status Flag "fixed" to find out with what version a particular problem became solved by a fix.
- For RESOLVED - WORKSFORME or similar resolution: Shows the earliest SeaMonkey version behind Version for what the bug now longer is reproducible (fix unknown)
Together with Version, Target Milestone marks the Range of (SeaMonkey) versions with the reported problem. This range-information is important for several useful Bugzilla-Queries, for example
- Decision whether you should update to a later version or whether that version contains regressions which are fatal for you.
- This example (Bugzilla account required) shows a query for the decision "should I update from SeaMonkey 2.40 to 2.47?". It lists problems (some still UNCONFIRMED) which appeared after Version 2.40, but still have not become FIXED for Target Miestone 2.47.
Resolution
- DUPLICATE or INVALID for accidentally created clones?
- Sometimes a bug report ends up in the Bugzilla database twice in a row. If you see two bugs with the same summary and adjacent bug numbers, mark one as INVALID. DUPLICATEs are indication that the problem affects many users or appears in different components (or may be the bug description is not optimum). The DUPLICATEs, what might contain important additional information, will have to be included into the Bug proceeding process, and especially when a fix is available it should be tested for all aspects mentioned in the DUPLICATEs. An accidentally created clone simply is INVALID and worthless for the bug fixing process. To avoid unnecessary interest for that clone, don't mention it in "See Also" of the remaining Bug report (or anywhere else), only leave a comment in the clone referring to the remaining Bug Report like "Accidentally created clone of Bug 123456".
Whiteboard
Should be used for search strings suitable for Bugzilla queries. That means Whiteboard entries should "tag" common characteristics of Bugs with the same Whiteboard entries. For important bug report internal ints (Workaround: see comment 17) pleas use field "User Story"
SeaMonkey internal Whiteboard tags
Please only use for Products with SeaMonkey in it's name andcopy/paste the tag from here to whiteboard field.
- [easyconfirm]
- for Bugs suitable for QA beginners. Report has a good step by step instruction how to reproduce, but still additional information will be required.
- [good first bug]
- for Bugs suitable for new developers. Report has a good step by step instruction how to reproduce, and it seems that the bug can be fixed easily if the volunteers has skills in the required area.
QA Whiteboard
To be continued
