Difference between revisions of "Bug Reporting FAQ"
(→Folders and Work Flow)
|Line 60:||Line 60:|
change, it may remain unaddressed forever.
change, it may remain unaddressed forever.
Revision as of 19:08, 18 October 2006
- 1 Introduction
- 2 Bug Reporting References
- 3 Cool Things in Bugzilla
- 4 Folders and Work Flow
- 5 Bug Entry
- 5.1 What is the difference between "Report a new bug" and “Enter a feature request”?
- 5.2 How are the values for Platform and OS filled in on the bug entry form?
- 5.3 What is the difference between Severity and Priority?
- 5.4 How do I find a particular bug number?
- 5.5 How do I search for bugs containing certain text?
- 5.6 Query Hints
- 5.7 What is the “My Bugs” link on the footer of most Bugzilla pages?
- 6 Miscellaneous
Eclipse bug reporting is done through an Bugzilla, a popular open source bug tracking system. This page will highlight a few cool features of Bugzilla that may not be immediately obvious and will answer questions about bug entry and searching.The gateway to the Eclipse bug database is: https://bugs.eclipse.org/bugs and it is also linked off of www.eclipse.org.
Bug Reporting References
- The Bugzilla Guide - The user manual for Bugzilla produced by the Bugzilla team.
- How to Report Bugs Effectively - Excellent tips on writing quality bug reports.
- Bug Writing Guidelines - Bug writing guidelines from the Bugzilla team.
Cool Things in Bugzilla
Bug Entry Templates
After filling in some or all of the fields on the new bug form (or the feature request form) you can press the “Remember values as bookmarkable template” button. Following the simple instructions on the resulting page will leave you with a bookmark that will take you to a new bug entry page with the fields filled in with the values you have specified. Hint: The template will include all the fields that you filled in so you may not want to enter Summary or Description text as part of your template.
Named, Saved and Bookmarked Queries
The main query page can be found at https://bugs.eclipse.org/bugs/query.cgi. Near the bottom of the query page you have options to:
- Remember the current settings as the default for this page each time it is loaded.
- Name the query for reuse later (each user has their own set of named queries).
- Name the query for later reuseand add a link to the named query to your page footer for quick access.
Use your user preferences link to manage named queries (https://bugs.eclipse.org/bugs/userprefs.cgi?bank=footer). Select a previously saved named query (this combo box only appears near the bottom of the query page if you have at least one named query saved)
The “Reports” link on the footer of most Bugzilla pages takes you to a form that can summarize bug counts in interesting ways. The link is: https://bugs.eclipse.org/bugs/reports.cgi
Form Fill In
You may want to turn on the form fill in feature of Internet Explorer. This will provide drop down lists for picking values you have commonly entered into text fields in the various Bugzilla forms. This option can be found in the Internet Explorer menus Tools->Internet Options->Content->AutoComplete
Folders and Work Flow
What is the life cycle of a bug report?
When a new bug is entered it begins life with a Status of either Unconfirmed for normal users or New for users with commit privileges. The bug is typically assigned to the component owner. The component owner will usually use a query of Status = Unconfirmed or New and Assinged to = me to browse what is essentially the component's inbox. She or he will assign bug reports to developers. Email will be generated to the developer (this part is configurable). (Note that the act of reassigning a bug to somebody changes its status to New). The developer may change unconfirmed bugs to new.
The assigned developer will “accept” the bug which will change its status to Assigned. After working on the bug the developer will mark the bug as Resolved and will select a resolution (Fixed, Invalid, Wontfix, Later, Remind, Worksforme).
Once a bug is resolved there are still a few states it can transition too. How you choose to use these states will be up to individual teams. In our example, when a test pass comes up a component owner can build a query that searched for resolved bugs. After testing that the fix worked a resolved bug can be transitioned to verified, directly to closed, or in fact, reopened. By searching for bugs with a Status of verified and a resolution of fixed developers can come up with release notes. A verified/fixed bug can then be transitioned to closed. And yes, closed bugs can be reopened if need be. As an added bonus other bug status can be transitioned through verified to closed as well. This gives developers the opportunity to test worksforme claims.
How do I find a bug if all I know is the old RPRS PRID
RPRS is the problem tracking system used by the Eclipse team before we switched to Bugzilla. RPRS PRID's are 7 character ID's with a mix of numbers and letters (e.g. 1GETAYN). The RPRS PRID has been added to the end of each bug report summary (title) that was converted from the old system. So to find a bug report based on the PRID simply perform a search of the summary with the PRID. Searching is covered later on in this FAQ.
How can I get my enhancements in the committer's queue?
Please see 'Why do some bugs stay RESOLVED/LATER for years?'
Why do some bugs stay RESOLVED/LATER for years?
As quoted from Bug 157642 Comment 14:
For most committers, there is an effectively unlimited supply of available bug reports and enhancement requests. How they choose what to work on is effectively a cost/benefit analysis. Cost in this case is the amount of work to address it, the work of ongoing maintenance for a new feature, the ripple cost a new feature may have on downstream projects, performance cost, etc. Things that increase the "benefit" side include benefits for end-users of Eclipse applications, benefits for downstream projects, etc. Also, input from the community in the form of votes, and input from the PMC and from committers on other projects increase the "benefit" side of the equation. A long-dormant bug may be reopened either because the cost has gone down (perhaps some underlying infrastructure is now available that makes the problem easier to solve), or the benefit has gone up (more requests from users, committers on other projects, the PMC, etc). If the cost/benefit ratio of a bug does not change, it may remain unaddressed forever.
Why is using RESOLVED/LATER bad?
Bugzilla doesn't ship by default with either a RESOLVED LATER or RESOLVED REMIND state. The reason why it doesn't is because where the bug is in its lifecycle (NEW, ASSIGNED, RESOLVED) should be independent of when it is planned to be fixed.
Instead, Bugzilla provides a better way of handling this: you can leave the bug in the NEW state, but just update the 'target milestone' to be LATER (each project has its own milestones, so each project will need to add a target milestone of LATER to make this work). That way, the bug is still in an OPEN state (as opposed to a CLOSED state, as defined in the bugzilla statuses document) and as such, comes up in any search looking for open bugs. However, you've still got the ability to filter out the LATER milestones in your reports, if you want to.
What is the difference between "Report a new bug" and “Enter a feature request”?
"Enter a feature request" provides a simplified form to enter information pertaining to a suggested enhancement. Certain fields are automatically saved with default values. When a feature request is entered it is stored in the regular bug database along with the bugs. Feature severities are automatically set to "Enhancement"
How are the values for Platform and OS filled in on the bug entry form?
These fields are set based on information provided automatically by your browser. In general they will reflect the Platform and OS you are using when you enter the bug. Please be sure to change these to accurately reflect the bug you are entering. Feature requests have Platform and OS set to “All”.
What is the difference between Severity and Priority?
Severity is assigned by a user and describes the level of impact the bug is having on them. Priority is assigned by the developer and describes the importance a developer places on fixing the bug. P1 is the highest priority, P5 is the lowest. Searching
How do I find a particular bug number?
There are several ways to do this:
- Use the Quick Search box on: https://bugs.eclipse.org/bugs.
- Type the bug number in the bug # action box on the footer of most Bugzilla pages.
- Put the bug number in the “Only bugs numbered” field on the main query page at: https://bugs.eclipse.org/bugs/query.cgi
How do I search for bugs containing certain text?
There are several ways to do this:
- Use the Quick Search box on: https://bugs.eclipse.org/bugs. This box will only perform a case insensitive search on bug summaries. It will not search descriptions or comments.
- Fill in the “Summary” and/or “A description entry:” fields on the main query page at: https://bugs.eclipse.org/bugs/query.cgi. The “description entry” field will search the initial description and all the comments of a bug report.
Note that the bug # field in the footer of most Bugzilla pages can not be used to search for text.
The “Status”, “Resolution”, “Platform”, “OpSys”, “Priority” and “Severity” multi-select list boxes on the main query page (https://bugs.eclipse.org/bugs/query.cgi) only need to be set if you want to limit your query to certain values for these fields. If you want to search for bugs with any status no items in the “Status” list should be selected. It is not necessary to select all the items in the list.
The main query page is described in great detail at: https://bugs.eclipse.org/bugs/queryhelp.cgi
This is a predefined query for bugs that are New, Assigned or Reopened and that where reported by or assigned to you. You may not change this predefined query but you can remove the link from your footer using the “prefs” link on the footer.
Why am I getting so much email and how can I make it stop
Go to the “Change password or user preferences” link off the main page (https://bugs.eclipse.org/bugs/userprefs.cgi) and select Email settings. Change your settings to suite your preferences.
What are Keywords
Key words are a set of defined words that can be associated with a bug report. Quick searches can be done on keywords. The following points should be kept in mind about keywords:
- They are defined by the Bugzilla maintainer. Send requests for new key words to the Bugzilla maintainer.
- They are case insensitive.
- They can not be added to a bug report when it is first created. They can only be added when editing a bug report.
- The keywords are described at: https://bugs.eclipse.org/bugs/describekeywords.cgi