- If the issue is a duplicate, close it as such.
- If the issue belongs to a different component, make sure the state is 'New' and transfer it to the correct component.
- If the issue is incomplete, add a comment noting what is needed and close the bug as 'Resolved' - 'Incomplete'. This is our way of saying "need more information".
- If the issue is complete:
- ensure the priority is correct
- ensure the 'Affects Version/s' field is correct (within reason)
- this may involve reproducing the bug, if doing so is fast and easy
- set the 'Fix Version/s'
- a bug should be fixed in the most recent version where it exists
- if the bug also exists in older versions it may require backporting to those
- the decision to backport should be made in agreement with those responsible for the relevant update release
- create backport issue(s) once it is agreed that the bug should be backported
Fix version must be a singular value for JBS issues. Unfortunately we can't stop JIRA from allowing it to have multiple values.
- make sure the bug has all the required labels
- bugs that are new in the current release: 'regression'
- bugs that was introduced after the last upstream integration: 'integration_blocker'
- bugs that do not affect product code, but only tests: 'testbug'
- issues that seems to be really trivial to fix: 'starter'
- RFEs that are pure cleanups: 'cleanup'
- project specific issues usually have their own labels as well
- bring high priority (P1, P2, or integration_blocker) bugs to the attention of the component team; assign the bug to an engineer
- 'Triage' the issue so that it moves to the 'Open' state
|Also consult Bug Triage for Filing bugs for HotSpot failures for details on what information that should be included in a bug.|