Child pages
  • A guide to raising OpenAM bugs
Skip to end of metadata
Go to start of metadata

Introduction

When you are raising an OpenAM bug there are number of important fields that must be completed accurately otherwise problems will occur later on in the release cycle.

Raising a bug from a support case

If you are raising a bug as a result of a support case; the support case id must be set as the case id field in the bugster ticket.

 

Affects Versions

When you are raising a bug; you must set the versions affected by the issue. Bugs that have just been discovered will likely affect all previous versions. Bugs in new product areas such as entitlements will only affect versions newer than OpenSSO Build 8.

Fix Versions

Setting fix versions is vital if the bug is going to be properly tracked and reported. Selecting the correct fix versions breaks down like this:

  • RFE/Improvement: If this is new code then it is likely just to be going into the next new release. In which case select the next upcoming release candidate. If the current release is 9.5.3 then the next new release would be 10_RC1. 
  • Bug: If the issue a bug and it only affects new versions then tag the next upcoming release candidate (e.g.: 10_RC1) or if the bug is urgent/serious release (e.g.: 10). If the bug is against the maintenance release (such as 9.5.x) then the bug should be tagged against the next maintenance release candidate (such as 9.5.4_RC1) and the next trunk release candidate (such as 10_RC1).

Description

Make sure the contents of the description contains enough information to allow someone else search bugster can find the bug. A good example is if the bug produces a stack trace then ensure the stack trace is included in the description.

  • No labels