Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Eclipse/Bug Tracking"

(Added "common queries" section)
Line 87: Line 87:
  
 
There is also an "iplog" flag for the entire bug report next to the "review" and "pmc_approved" flags.  This flag should only be used if the contribution is not in the form of an attachment. For example, you can use this if the contributor added code or pseudo-code directly in the comment field.  The simple solution in this case is to ask the contributor to attach a proper patch so it can be flagged. If this is not possible or the contributor doesn't respond, you can resort to setting the global "iplog" flag on the bug itself. What this flag does is flag every non-committer who added a comment to the bug as contributors. If there are comments in the same bug that are not part of the contribution, they then need to be excluded manually by editing the project IP log. This is a painful process, so using attachments to track contributions is always preferred if possible. See the IP log documentation for more details: [[Development_Resources/Automatic_IP_Log#Contributors]]  
 
There is also an "iplog" flag for the entire bug report next to the "review" and "pmc_approved" flags.  This flag should only be used if the contribution is not in the form of an attachment. For example, you can use this if the contributor added code or pseudo-code directly in the comment field.  The simple solution in this case is to ask the contributor to attach a proper patch so it can be flagged. If this is not possible or the contributor doesn't respond, you can resort to setting the global "iplog" flag on the bug itself. What this flag does is flag every non-committer who added a comment to the bug as contributors. If there are comments in the same bug that are not part of the contribution, they then need to be excluded manually by editing the project IP log. This is a painful process, so using attachments to track contributions is always preferred if possible. See the IP log documentation for more details: [[Development_Resources/Automatic_IP_Log#Contributors]]  
 +
 +
== Common, routine, Team Bugzilla queries ==
 +
 +
=== Open bugs per milestone target ===
 +
 +
These queries are especially handy as we near the end of a release, or milestone -- to see what still needs to be triaged.
 +
{{Note| We include Equinox/p2 bugs here, too, but they follow a different convention for "target names", which is why some show up as "4.5 M3" vs "Mars M3" for example.}}
 +
{{Tip| As development progresses, it is best to leave past milestones selected, as well as adding the next one. That way, if a bug is re-opened, and target not adjusted, it will not get "lost" so easily and provide a nice reminder to adjust the target milestone.}}
 +
 +
* Luna
 +
: [https://bugs.eclipse.org/bugs/report.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Eclipse&classification=RT&product=Equinox&product=JDT&product=PDE&product=Platform&target_milestone=4.4&target_milestone=4.4%20M1&target_milestone=4.4%20M2&target_milestone=4.4%20M3&target_milestone=4.4%20M4&target_milestone=4.4%20M5&target_milestone=4.4%20M6&target_milestone=4.4%20M7&target_milestone=4.4%20RC1&target_milestone=4.4%20RC2&target_milestone=4.4%20RC3&target_milestone=4.4%20RC4&target_milestone=4.4.1&target_milestone=4.4.2&target_milestone=Luna&target_milestone=Luna%20M1&target_milestone=Luna%20M2&target_milestone=Luna%20M3&target_milestone=Luna%20M4&target_milestone=Luna%20M5&target_milestone=Luna%20M6&target_milestone=Luna%20M7&target_milestone=Luna%20RC1&target_milestone=Luna%20RC2&target_milestone=Luna%20RC3&target_milestone=Luna%20RC4&target_milestone=Luna%20SR1&target_milestone=Luna%20SR2&x_axis_field=bug_severity&y_axis_field=component&z_axis_field=target_milestone&format=table&action=wrap&saved_report_id=19 Current, open bugs for Luna SR2]
 +
 +
* Mars
 +
 +
: [https://bugs.eclipse.org/bugs/report.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Eclipse&classification=RT&component=Ant&component=API%20Tools&component=APT&component=build&component=Compare&component=Compendium&component=components&component=Core&component=CVS&component=Debug&component=Doc&component=Framework&component=IDE&component=Launcher&component=p2&component=PMC&component=Releng&component=Resources&component=Runtime&component=Scripting&component=Search&component=Security&component=Server-Side&component=SWT&component=Team&component=Text&component=UI&component=User%20Assistance&component=Weaving&component=WebDAV&component=Website&product=Equinox&product=JDT&product=PDE&product=Platform&target_milestone=4.5%20M1&target_milestone=4.5%20M2&target_milestone=4.5%20M3&target_milestone=Mars%20M1&target_milestone=Mars%20M2&target_milestone=Mars%20M3&x_axis_field=bug_severity&y_axis_field=component&z_axis_field=target_milestone&format=table&action=wrap&saved_report_id=33 Current, open bugs for Mars M3]
  
 
[[Category:Eclipse Project]]
 
[[Category:Eclipse Project]]

Revision as of 13:49, 21 September 2014

Overview

The Eclipse Project uses Eclipse Bugzilla for bug tracking. This page provides details on how the Eclipse project uses bugzilla.

Bugzilla Fields

Product

The Eclipse Project uses the following values for the bugzilla Product field:

  • Platform
  • JDT
  • PDE
  • E4
  • Incubator

Target Milestones

The 'Target Milestone' field lists the Milestone or Release in which a bug is intended to get fixed or was first fixed. The fix can be assumed to be present in all milestones or releases after that point, unless otherwise specified in the bug. The notation used is as follows:

  • x.y.z - indicates a final release build in which the fix/enhancement was made
  • x.y.z M# - indicates a milestone build in which the fix/enhancement was made
  • x.y.z RC# - indicates a release candidate build in which the fix/enhancement was made
  • 2.0 F# - indicates a release candidate build from the 2.0 release. The term freeze was replaced with release candidate in subsequent releases
  • x.y.z+ - indicates the fix was made after the x.y.z release, and was released into the Rx_y_maintenance branch in CVS corresponding to that release. If a hypothetical x.y.(z+1) release were to occur, it would contain the release, but no such release is scheduled. For example 3.4.2+ indicates the fix was released in the R3_4_maintenance branch in CVS sometime after the 3.4.2 release, and would be included in a theoretical 3.4.3 release if such a release occurred.

Priority

Priority is set by the committer or contributor that the bug is assigned to, or by the component owner. This roughly indicates the importance of the bug/enhancement relative to the other bugs/enhancements owned by the committer or component.

Priority Definition
1
Must fix for the indicated target milestone. Literally. We will slip dates for P1's, so use sparingly.
2
Very important for the indicated target milestone. Nearly all P2's should be resolved, so do not over use.
3
Of normal importance. Default starting point. While triaging a bug it is good to consider its priority and adjust higher or lower if appropriate.
4
Less important. Would like to fix the bug, time permitting.
5
A valid bug, but no plans to investigate further or fix. All P5 bugs also imply 'helpwanted', but 'helpwanted' can also be used on any other priority.

Severity

Severity is set by the person who reported the bug. The bug owner can change the severity or request the originator do so if their description of the problem is inconsistent with the definition of the severity. However, the severity represents the originator's perspective and should not be changed by others purely because they have a different perspective. For example if the originator only uses Eclipse for spell-checking, and the spell-checking function is not working, they can fairly say the bug is blocking even though from the committer's perspective it is only a major problem.

Severity Definition
Blocker
Blocks development and/or testing work. No workaround exists.
Critical
Crashes, loss of data, severe memory leak.
Major
Major loss of function.
Normal
Regular issue, some loss of functionality under specific circumstances.
Minor
Minor loss of function, or other problem where easy workaround is present.
Trivial
Cosmetic problem such as misspelled words or misaligned text.
Enhancement
Request for enhancement.

Tracking IP Contributions

IP contributions are tracked in bugzilla using the "iplog" flag. The "iplog" flag should be set on the *attachment* that contains the contribution. This is done by clicking "Details" next to the attachment, and then setting the "iplog" flag for that attachment. If there are multiple attachments being contributed, add the flag for each applicable attachment. This allows the system to automatically harvest data about the size of the contribution, who contributed it (the person who added the attachment), and the committer who processed the contribution (the person who set the "iplog+" flag).

Note: it doesn't matter if the attachment from the contributor is obsolete. If you have taken a contribution from someone, and made a few small changes and attached a new patch, you should still flag the obsolete patch with iplog+ to record the contribution that the fix was based on.

There is also an "iplog" flag for the entire bug report next to the "review" and "pmc_approved" flags. This flag should only be used if the contribution is not in the form of an attachment. For example, you can use this if the contributor added code or pseudo-code directly in the comment field. The simple solution in this case is to ask the contributor to attach a proper patch so it can be flagged. If this is not possible or the contributor doesn't respond, you can resort to setting the global "iplog" flag on the bug itself. What this flag does is flag every non-committer who added a comment to the bug as contributors. If there are comments in the same bug that are not part of the contribution, they then need to be excluded manually by editing the project IP log. This is a painful process, so using attachments to track contributions is always preferred if possible. See the IP log documentation for more details: Development_Resources/Automatic_IP_Log#Contributors

Common, routine, Team Bugzilla queries

Open bugs per milestone target

These queries are especially handy as we near the end of a release, or milestone -- to see what still needs to be triaged.

Note.png
We include Equinox/p2 bugs here, too, but they follow a different convention for "target names", which is why some show up as "4.5 M3" vs "Mars M3" for example.
Idea.png
As development progresses, it is best to leave past milestones selected, as well as adding the next one. That way, if a bug is re-opened, and target not adjusted, it will not get "lost" so easily and provide a nice reminder to adjust the target milestone.


  • Luna
Current, open bugs for Luna SR2
  • Mars
Current, open bugs for Mars M3

Back to the top