Difference between revisions of "Bug Reporting FAQ"

From Eclipsepedia

Jump to: navigation, search
(How do I find a particular bug number?)
(What is the difference between Severity and Priority?)
(14 intermediate revisions by 6 users not shown)
Line 16: Line 16:
 
* Remember the current settings as the default for this page each time it is loaded.
 
* 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 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.  
+
* 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 [http://www.bugzilla.org/docs/tip/en/html/query.html 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)
+
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).
  
 
===Bug Counts===
 
===Bug Counts===
Line 36: Line 36:
 
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).
 
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 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.
+
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===
 
===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.
 
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?===
+
===How can I get my enhancements (or bug fix requests) in the committer's queue?===
Please see 'Why do some bugs stay RESOLVED/LATER for years?'
+
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 [[How to report a deadlock|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.
  
===Why do some bugs stay RESOLVED/LATER for years?===
+
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 [https://bugs.eclipse.org/bugs/show_bug.cgi?id=157642#c14 Bug 157642 Comment 14]:
 
As quoted from [https://bugs.eclipse.org/bugs/show_bug.cgi?id=157642#c14 Bug 157642 Comment 14]:
Line 62: Line 66:
 
other projects, the PMC, etc).  If the cost/benefit ratio of a bug does not
 
other projects, the PMC, etc).  If the cost/benefit ratio of a bug does not
 
change, it may remain unaddressed forever.
 
change, it may remain unaddressed forever.
 
===Why is using RESOLVED/LATER bad?===
 
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
 
[https://bugs.eclipse.org/bugs/page.cgi?id=fields.html#status 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.
 
 
===Deprecated resolutions===
 
The LATER and REMIND resolutions are obsolete. Please see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=178923#c75 Bug 178923 Comment 75] for more information.
 
 
  
 
==Bug Entry==
 
==Bug Entry==
Line 84: Line 75:
  
 
===What is the difference between Severity and Priority?===
 
===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.
+
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 prevents use or testing of the build (for which there is no work-around)
 +
* "critical" implies "loss of data" or frequent crashes
 +
* "major" implies "loss of function"
 +
* "normal" ... default value, typically the correct setting unless one of the other levels fit
 +
* "minor" means something's wrong, but doesn't affect function significantly
 +
* "trivial" means something's wrong, but doesn't affect function (such as spelling errors in doc, etc.)
 +
* "enhancement" is for feature requests (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.
 +
 
 
==Searching==
 
==Searching==
  
Line 93: Line 99:
 
* Type the bug number in the bug # action box on the footer of most Bugzilla pages.
 
* 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
 
* 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: https://bugs.eclipse.org/12345
+
* You can also use a short link, for example: http://bugs.eclipse.org/12345
  
 
===How do I search for bugs containing certain text?===
 
===How do I search for bugs containing certain text?===
Line 104: Line 110:
  
 
===Query Hints===
 
===Query Hints===
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 “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.
  
 
===What is the “My Bugs” link on the footer of most Bugzilla pages?===
 
===What is the “My Bugs” link on the footer of most Bugzilla pages?===
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.
+
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?===
 
===How do you search by relative dates?===
Line 131: Line 137:
  
 
===What is the Whiteboard===
 
===What is the Whiteboard===
The whiteboard is used to instead of keywords for certain things (I have no idea why we don't use keywords for these things). At least one of those is:
+
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. 
* haspatch - indicates the bug report contains a patch
+
  
 
[[Category:FAQ]][[Category:How to Contribute]]
 
[[Category:FAQ]][[Category:How to Contribute]]
 +
 +
=== 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 webmaster@eclipse.org.  For more information about Bug Triage, please see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=265880 Bug 265880]

Revision as of 12:26, 12 November 2012

Contents

Introduction

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.

Bug Reporting References

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).

Bug Counts

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

Autolinkification

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.

Bug Entry

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.

The levels generally have the following meanings:

  • "blocker" means just that, the bug prevents use or testing of the build (for which there is no work-around)
  • "critical" implies "loss of data" or frequent crashes
  • "major" implies "loss of function"
  • "normal" ... default value, typically the correct setting unless one of the other levels fit
  • "minor" means something's wrong, but doesn't affect function significantly
  • "trivial" means something's wrong, but doesn't affect function (such as spelling errors in doc, etc.)
  • "enhancement" is for feature requests (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.

Searching

How do I find a particular bug number?

There are several ways to do this:

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.

Query Hints

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.

What is the “My Bugs” link on the footer of most Bugzilla pages?

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 - Today's date/time.
  • -1w - One week ago.
  • -1d - One day ago.
  • -1y - One year ago.
  • -1h - One hour ago.

Miscellaneous

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 webmaster@eclipse.org. For more information about Bug Triage, please see Bug 265880