Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
WTP/Hotbug Policy
Purpose
This document describes what a "hotbug" is, in WTP, and the process involved for submitting a hotbug request.
Hotbug request
A hotbug_request is simply a way for an adopter (with no committers on a project) to document what they think the priority of a bug should be. It essentially means a "P1" from that adopters point of view. Committers do not need to use "hotbug" ... they can simply use "P1" as is their committer privilege.
Any (non-committer) adopter can submit a hot bug request; where adopters means some other Eclipse project, some other open source project, or some product adopter. If you are the originator of the bug (that is, you opened it), simply prefix the bugzilla abstract with [hotbug_request]. If you do not have authorization to change the abstract of a bug (that is, you didn't open it) then you will need to get a committer to mark it for you. In either case, you should include the following information in the bugzilla:
- Affiliation (Company, other open source project, or adopting Eclipse Project)
- Be clear on which release you want this bug to be fixed in or your patched applied, or the "last workable" date, if need before a literally release (e.g. for testing, adoption).
- Justify why this is a hotbug. Note that "our users don't like the bug" is not the type of reason that gets much attention. The motivation we are looking for to justify a P1-like hotbug priority is, something similar to, "this bug blocks our adoption of WTP because ... " (explaining why, of course).
Hotbug
If a hot bug request is accepted, the assignee should.
- Change the bugzilla prefix from [hotbug_request] to [hotbug].
- Set the milestone target field to reflect the requested release.
Note that "accepting" the hotbug simply means it is understood what the bug is, and it is agreed it fits the category of hotbug.
There is no commitment to fix it, just because its marked as hotbug.
So what is the effect of marking hotbug?
Hotbugs are reviewed in status meetings, along with "P1" bugs.
Also, one reason we provide this marking of "hotbug" is to help make the severity more accurate. Without it, we often find people open bugs as "critical" to reflect "really important" whereas severity should reflect the impact of a bug (for example, "critical" means "loss of data"). So, if a bug's severity is mismarked, then the originator might get a reputation for being shrill and and will receive less attention in the future. Thus, it is to your advantage to mark severity accurately and denote priority accurately. For guidance, see WTP Conventions of bug priority and severity.
Adopters who request the hotbug designation should be prepared to submit a patch to fix the issue. The owning team will definitely investigate the issue and in some cases be able to fix it by the time requested, but there is no commitment to do so. In many cases they may not be able fix it due to their own priorities and business needs. An attached patch always gets more attention and a high quality patch will always be accepted for a hotbug.