This section contains information for end-users of Bugzilla. - There is a Bugzilla test installation, called - Landfill, - which you are welcome to play with (if it's up.) - However, it does not necessarily - have all Bugzilla features enabled, and often runs cutting-edge versions - of Bugzilla for testing, so some things may work slightly differently - than mentioned here.
If you want to use Bugzilla, first you need to create an account. - Consult with the administrator responsible for your installation of - Bugzilla for the URL you should use to access it. If you're - test-driving Bugzilla, use this URL: - http://landfill.bugzilla.org/bugzilla-tip/. -
Click the - "Open a new Bugzilla account" - - link, enter your email address and, optionally, your name in the - spaces provided, then click - "Create Account" - - .
Within moments, you should receive an email to the address - you provided above, which contains your login name (generally the - same as the email address), and a password you can use to access - your account. This password is randomly generated, and can be - changed to something more memorable.
Click the - "Log In" - link in the yellow area at the bottom of the page in your browser, - enter your email address and password into the spaces provided, and - click - "Login". -
You are now logged in. Bugzilla uses cookies for authentication - so, unless your IP address changes, you should not have to log in - again.
The core of Bugzilla is the screen which displays a particular - bug. It's a good place to explain some Bugzilla concepts. - Bug 1 on Landfill - - is a good example. Note that the labels for most fields are hyperlinks; - clicking them will take you to context-sensitive help on that - particular field. Fields marked * may not be present on every - installation of Bugzilla.
Product and Component: - Bugs are divided up by Product and Component, with a Product - having one or more Components in it. For example, - bugzilla.mozilla.org's "Bugzilla" Product is composed of several - Components: -
| Administration: - Administration of a Bugzilla installation. |
| Bugzilla-General: - Anything that doesn't fit in the other components, or spans - multiple components. |
| Creating/Changing Bugs: - Creating, changing, and viewing bugs. |
| Documentation: - The Bugzilla documentation, including The Bugzilla Guide. |
| Email: - Anything to do with email sent by Bugzilla. |
| Installation: - The installation process of Bugzilla. |
| Query/Buglist: - Anything to do with searching for bugs and viewing the - buglists. |
| Reporting/Charting: - Getting reports from Bugzilla. |
| User Accounts: - Anything about managing a user account from the user's perspective. - Saved queries, creating accounts, changing passwords, logging in, - etc. |
| User Interface: - General issues having to do with the user interface cosmetics (not - functionality) including cosmetic issues, HTML templates, - etc. |
Status and Resolution: - - These define exactly what state the bug is in - from not even - being confirmed as a bug, through to being fixed and the fix - confirmed by Quality Assurance. The different possible values for - Status and Resolution on your installation should be documented in the - context-sensitive help for those items.
Assigned To: - The person responsible for fixing the bug.
*URL: - A URL associated with the bug, if any.
Summary: - A one-sentence summary of the problem.
*Status Whiteboard: - (a.k.a. Whiteboard) A free-form text area for adding short notes - and tags to a bug.
*Keywords: - The administrator can define keywords which you can use to tag and - categorise bugs - e.g. The Mozilla Project has keywords like crash - and regression.
Platform and OS: - These indicate the computing environment where the bug was - found.
Version: - The "Version" field is usually used for versions of a product which - have been released, and is set to indicate which versions of a - Component have the particular problem the bug report is - about.
Priority: - The bug assignee uses this field to prioritise his or her bugs. - It's a good idea not to change this on other people's bugs.
Severity: - This indicates how severe the problem is - from blocker - ("application unusable") to trivial ("minor cosmetic issue"). You - can also use this field to indicate whether a bug is an enhancement - request.
*Target: - (a.k.a. Target Milestone) A future version by which the bug is to - be fixed. e.g. The Bugzilla Project's milestones for future - Bugzilla versions are 2.18, 2.20, 3.0, etc. Milestones are not - restricted to numbers, thought - you can use any text strings, such - as dates.
Reporter: - The person who filed the bug.
CC list: - A list of people who get mail when the bug changes.
Attachments: - You can attach files (e.g. testcases or patches) to bugs. If there - are any attachments, they are listed in this section.
*Dependencies: - If this bug cannot be fixed unless other bugs are fixed (depends - on), or this bug stops other bugs being fixed (blocks), their - numbers are recorded here.
*Votes: - Whether this bug has any votes.
Additional Comments: - You can add your two cents to the bug discussion here, if you have - something worthwhile to say.
The Bugzilla Search page is is the interface where you can find - any bug report, comment, or patch currently in the Bugzilla system. You - can play with it here: - http://landfill.bugzilla.org/bugzilla-tip/query.cgi.
The Search page has controls for selecting different possible - values for all of the fields in a bug, as described above. For some - fields, multiple values can be selected. In those cases, Bugzilla - returns bugs where the content of the field matches one of the selected - values. If none is selected, then the field can take any value.
Once you've defined a search, you can either run it, or save it - as a Remembered Query, which can optionally appear in the footer of - your pages.
Highly advanced querying is done using Boolean Charts.
If you run a search, a list of matching bugs will be returned. - The default search is to return all open bugs on the system - don't try - running this search on a Bugzilla installation with a lot of - bugs!
The format of the list is configurable. For example, it can be - sorted by clicking the column headings. Other useful features can be - accessed using the links at the bottom of the list: -
| Long Format: - - this gives you a large page with a non-editable summary of the fields - of each bug. |
| Change Columns: - - change the bug attributes which appear in the list. |
| Change several bugs at once: - - If your account is sufficiently empowered, you can make the same - change to all the bugs in the list - for example, changing their - owner. |
| Send mail to bug owners: - - Sends mail to the owners of all bugs on the list. |
| Edit this query: - - If you didn't get exactly the results you were looking for, you can - return to the Query page through this link and make small revisions - to the query you just made so you get more accurate results. |
Years of bug writing experience has been distilled for your - reading pleasure into the - Bug Writing Guidelines. - While some of the advice is Mozilla-specific, the basic principles of - reporting Reproducible, Specific bugs, isolating the Product you are - using, the Version of the Product, the Component which failed, the - Hardware Platform, and Operating System you were using at the time of - the failure go a long way toward ensuring accurate, responsible fixes - for the bug that bit you.
The procedure for filing a test bug is as follows:
Go to - Landfill - in your browser and click - Enter a new bug report. -
Select a product - any one will do.
Fill in the fields. Bugzilla should have made reasonable - guesses, based upon your browser, for the "Platform" and "OS" - drop-down boxes. If they are wrong, change them.
Select "Commit" and send in your bug report.
Viewing and reviewing patches in Bugzilla is often difficult due to - lack of context, improper format and the inherent readability issues that - raw patches present. Patch Viewer is an enhancement to Bugzilla designed - to fix that by offering increased context, linking to sections, and - integrating with Bonsai, LXR and CVS.
Patch viewer allows you to:
| View patches in color, with side-by-side view rather than trying - to interpret the contents of the patch. |
| See the difference between two patches. |
| Get more context in a patch. |
| Collapse and expand sections of a patch for easy - reading. |
| Link to a particular section of a patch for discussion or - review |
| Go to Bonsai or LXR to see more context, blame, and - cross-references for the part of the patch you are looking at |
| Create a rawtext unified format diff out of any patch, no - matter what format it came from |
The main way to view a patch in patch viewer is to click on the - "Diff" link next to a patch in the Attachments list on a bug. You may - also do this within the edit window by clicking the "View Attachment As - Diff" button in the Edit Attachment screen.
To see the difference between two patches, you must first view the - newer patch in Patch Viewer. Then select the older patch from the - dropdown at the top of the page ("Differences between [dropdown] and - this patch") and click the "Diff" button. This will show you what - is new or changed in the newer patch.
To get more context in a patch, you put a number in the textbox at - the top of Patch Viewer ("Patch / File / [textbox]") and hit enter. - This will give you that many lines of context before and after each - change. Alternatively, you can click on the "File" link there and it - will show each change in the full context of the file. This feature only - works against files that were diffed using "cvs diff".
To view only a certain set of files in a patch (for example, if a - patch is absolutely huge and you want to only review part of it at a - time), you can click the "(+)" and "(-)" links next to each file (to - expand it or collapse it). If you want to collapse all files or expand - all files, you can click the "Collapse All" and "Expand All" links at the - top of the page.
To link to a section of a patch (for example, if you want to be - able to give someone a URL to show them which part you are talking - about) you simply click the "Link Here" link on the section header. The - resulting URL can be copied and used in discussion. (Copy Link - Location in Mozilla works as well.)
To go to Bonsai to get blame for the lines you are interested in, - you can click the "Lines XX-YY" link on the section header you are - interested in. This works even if the patch is against an old - version of the file, since Bonsai stores all versions of the file.
To go to LXR, you click on the filename on the file header - (unfortunately, since LXR only does the most recent version, line - numbers are likely to rot).