Deprecated

This page is deprecated and it's content is either old or being moved to the OpenJDK Developers' Guide. Please update your links.


Each component team should perform bug triage at least two or three times a week. The purpose of the bug triage is to look through all new bugs assigned to the component since the last bug triage and make sure all issues are complete and properly prioritised. During the triage, engineers experienced in both JVM development and testing should be present. The participants form the triage team. The triage team should have the mandate to assign urgent issues directly to suitable engineers in the component team without delay.

To find what issues to look at during the triage there is a filter called Hotspot Untriaged that you can use together with a filter to find issues that belongs to your component team. HotSpot JBS components can be useful if you are unsure what subcomponents to include. Please note that this filter will not include issues transferred to your team that are in states other than 'New' (e.g. 'Open', 'In Progress'). A properly transferred bug should be in state 'New', but obviously there are no guaranties that all bugs are transferred properly. Use a separate JBS filter to look for bugs that has been updated recently, something like "updated > -7d".

It is recommended that the members of the triage team watch the suitable subcomponent(s) in JBS, to get notified when any issue in their area is updated.

Make sure all issues are complete

For all bugs and RFEs filed against (or transferred to) your component:

  1. If the issue is a duplicate, close it as such.
  2. If the issue belongs to a different component, make sure the state is 'New' and transfer it to the correct component.
  3. 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".
  4. If the issue is complete:
    1. ensure the priority is correct
    2. ensure the 'Affects Version/s' field is correct (within reason)
      1. this may involve reproducing the bug, if doing so is fast and easy
    3. set the 'Fix Version/s'
      1. a bug should be fixed in the most recent version where it exists
      2. if the bug also exists in older versions it may require backporting to those
        1. the decision to backport should be made in agreement with those responsible for the relevant update release
        2. 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.

    4. make sure the bug has all the required labels
      1. bugs that are new in the current release: 'regression'
      2. bugs that was introduced after the last upstream integration: 'integration_blocker'
      3. bugs that do not affect product code, but only tests: 'testbug'
      4. issues that seems to be really trivial to fix: 'starter'
      5. RFEs that are pure cleanups: 'cleanup'
      6. project specific issues usually have their own labels as well
    5. bring high priority (P1, P2, or integration_blocker) bugs to the attention of the component team; assign the bug to an engineer
    6. 'Triage' the issue so that it moves to the 'Open' state
Also consult Filing bugs for HotSpot failures for details on what information that should be included in a bug.

Oracle triage teams are not responsible for triaging and handling bugs in features or platforms that are not supported by Oracle. During triage it may still be necessary to handle these bugs in some way just to get them off the list. The recommended way to do that is to add the label 'openjdk'.

Please note that in the rampdown phases of each release it will still be the responsibility for each Oracle component team to make sure any issues assigned to external teams are either fixed or deferred. All OpenJDK contributors are asked to understand that this is necessary for the release, and when contacted for this reason, please reply promptly.

Ensure progress of incomplete bugs

It is also the triage team's responsibility to keep track of and ensure progress of incomplete bugs. It is not uncommon that incomplete bugs are forgotten due to the fact that they are in state 'Resolved' which most people filters out when looking in JBS. The triage team should go through incomplete bugs on a weekly basis and ping (email) the assignee if no progress has been made since the last week. If the required information is not received within a few weeks the bug can be 'Closed' as 'Incomplete'.