Bug Reporting FAQ
- 1 Introduction
- 2 Bug Reporting References
- 3 Cool Things in Bugzilla
- 4 Folders and Work Flow
- 5 Bug Entry
- 6 Searching
- 7 Miscellaneous
Eclipse bug reporting is done through a Bugzilla server, 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. It is also linked off of www.eclipse.org. To submit a bug report, you need an Eclipse account, which you can create at https://dev.eclipse.org/site_login/createaccount.php.
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 reuse and add a link to the named query to your page footer for quick access.
- Add a tag to a bug entry. Tags allow a handy "list of bugs" to be created and maintained by you, for your special purposes, without elaborate queries (such as, perhaps "classic" for bugs frequently asked about, or "thisweek" for bugs you plan to work on soon). See bugzilla documentation for more details.
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
Bugzilla automatically creates hyperlinks for certain text patterns, see http://www.bugzilla.org/docs/tip/html/hintsandtips.html. Here are some examples of automatically created links: Bug 2345 has a comment 4 (if linked from bug 2345), or bug 2345 comment 4 (if linked from another bug).
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 Assigned 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, Worksforme).
Once a bug is resolved there are still a few states it can transition to. 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 (or bug fix requests) in the committer's queue?
Usually, you should get a response from a committer on the bug, at least in the form of a change to the priority and/or target milestone fields. Make sure that you provide any additional information they request from you, such as log files (found at <workspace>/.metadata/.log), screenshots, or thread dumps. The more effort you invest in making it easy for the committer to understand and reproduce the problem, the more likely it is that your bug will be looked at soon.
If the conversation in a bug dies down, but you think that you've done everything you can on your side, it might be that the committer(s) who are watching the bug report have simply forgotten about it. Many committers are interrupt-driven, and if you don't abuse this, they will be glad for a gentle reminder. One or two weeks after the last comment would be a good time for a reminder.
Also see 'Why do some bugs stay open for years?'
Why do some bugs stay open 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.
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 the Bug priorities?
Severity is assigned by a user and describes the level of impact the bug is having on them.
The levels generally have the following meanings:
- "blocker" means just that, the bug blocks development or testing of the build (for which there is no work-around)
- "critical" implies "loss of data" or frequent crashes or a severe memory leak
- "major" implies "major loss of function"
- "normal" ... default value, regular issue, some loss of functionality under specific circumstances. Typically the correct setting unless one of the other levels fit
- "minor" means something's wrong, but doesn't affect function significantly or other problem where easy workaround is present
- "trivial" cosmetic problem like misspelled words or misaligned text, but doesn't affect function (such as spelling errors in doc, etc.)
- "enhancement" request for enhancement (also for "major" features that would be really nice to have)
But overall, it is up to each project do decide how they triage/handle bugs so some variability from project to project will occur.
Priority is assigned by the developer/committer and describes the importance a developer places on fixing the bug. P1 is the highest priority, P5 is the lowest.
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
- You can also use a short link, for example: http://bugs.eclipse.org/12345
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.
This is a predefined query for bugs that are New, Assigned or Reopened and that were 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.
How do you search by relative dates?
Under advanced search for date changed, you can enter a date in the form YYYY-MM-DD or a "relative date"... but it does not say how you enter a relative date. The syntax is:
- Now → Current date/time.
- 1h → One hour ago.
- 1d → One day ago (same as 24h).
- 1w → One week ago (same as 7d).
- 1y → One year ago.
If you want the beginning of the day, week or month, append an "s":
- 0ds → Start of this day.
- 1ds → Start of previous day.
- 0ws → Start of this week.
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
What is the Whiteboard
The whiteboard is used instead of keywords for certain things. The whiteboard is a free-form field that, usually, committers use for some temporary, short lived type of flag that doesn't deserve long term life as a keyword, and might only have meaning to the primary component team (not the community at large). For example, a team might temporarily use phrase such as 'haspatch' during some parts of their triage or development cycle to indicate "this is an old bug that has an old patch attached so deserves special attention this milestone to make sure we don't lose patches from community". As another example, a team might use "consider for 3.2.1 maintenance" which means they are not quite ready to target it to 3.2.1, but don't want to lose track of that possibility ... queries are often easier to write, and quicker to execute against some whiteboard phrase. Once a team is "done" with a whiteboard phrase, they can delete the text and then it's gone from the data base. A keyword, in contrast, stays around forever, pretty much, once added by administrators.
Bug Editing and Triage
A bug reporter has full control over his/her bug, but cannot change values of a bug they do not own. Only Eclipse Committers, and persons designated to bug triage, can edit/move/reassign bugs.
If you're an Eclipse committer and would like to nominate someone for bug triage, please send their Bugzilla account e-mail address to firstname.lastname@example.org. For more information about Bug Triage, please see Bug 265880