1. How bad is its impact? (Severity)
The impact is pretty bad. The fix is trivial and has no risk.
- Identify why the fix needs to occur now:
o Likely to generate a customer support call
2. How often does it happen? (Frequency)
3. How much effort is required to fix it? (Cost)
Zero cost – I have a fix ready to go. It is easy.
4. What is the risk of fixing it? (Risk)
Very Low risk.
5. Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
Yes and yes. It is the usual answer for any fouled-up command that exclusively sets config – the work-around is to use the low-level "set" command.
6. If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
7. How long has the bug existed in the product?
Since whenever the "deployment" module was added. It might be in 3.0
8. Do regression tests exist for this issue?
Yes. Monitoring DevTests detected the problem today!
9. Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
It's not that sort of issue. It is self-contained. To be very safe I would add a tiny minimal change in 3.1 branch and do the full change (change to ContainerMonitoring in the api package) to the trunk.
QA never tested it – it would have failed instantly.
10. When will a tested fix be ready for integration?
Code changes – a few minutes. Code review and red-tape – a few hours