This document describes the process involved for submitting a hot bug request, and how a request will be promoted to a hot bug.

Anyone can submmit a hot bug request. If you are the owner of the bug, simply prefix the bugzilla abstract with [hotbug_request]. You should include the following information in the bugzilla:

1. Affiliation
2. Release you want this bug to be fixed in
3. Justify why this is a hot bug and why it needs to be fixed in that release

If you are not the owner of the bug, please ask someone with appropriate bugzilla permissions to add the information for you. Alternatively, you can add hjzhang@ca.ibm.com to the bug's CC list and state your request. She will add the information for you. Note that at this point, this is only a hot bug request. WTP makes no commitment to fix it in the proposed release. The owner of this bug will work with the orginator on accepting or declining this request.

If a hot bug request is accepted, the bug owner should:

1. Update the target milestone field to reflect which release this bug will be fixed in.
2. Change the bugzilla prefix from [hotbug_request] to [hotbug].
3. Add hjzhang@ca.ibm.com to the CC list.

All unresolved hot bugs will be reviewed in each WTP status meeting. The hot bug originators are encouraged to attend these status meetings to support their hot bugs.

In the case where both the bug originator and the owner agree that a bug is no longer a hot bug, the owner should remove the [hotbug_request] prefix from the bugzilla abstract.

In the case where the bug originator and the owner cannot come to an agreement on whether a hot bug request should be promoted to a hot bug or not, the bug originator can attend the weekly WTP status meeting and request that the PMC members take a vote and make a final decision on whether the request should be promoted or not.

Each release, the PMC should decide on a hot bug submission cutoff date. After this date, only shop ships and regressions can be submitted as hot bugs.