This is the only workflow supported by OpenJDK to support development activities (e.g. bugs and feature requests).
A bug/feature request enters this status when it is created and should not remain in this status for more than 5 days.
Bugs with this status are effectively owned by the development triage team. The default "Assignee"/"Responsible Engineer" is "null". A bug may be analyzed by anybody who considers themselves part of that team. Successful triage requires skill at prioritization, resource management, and technical breadth.
- Open [ typical progression ]
When the Initial Evaluator (IE) (or other) can verify all of...- Category/subcategory is correct (assuming there are subcategories)
- Description contains sufficient information to verify/suspect that this is a real problem or to understand the feature request
- Priority complies with release standards and is computed based on questions for impact, likelihood, and workaround (ILW).
- Other basic information is correct or adjusted as necessary (reported release, synopsis, type (bug or feature), etc.)
- Targeted Release is set providing an initial estimate for analysis
Identification of a "Assignee"/"Responsible Engineer" is not required.
- Evaluated
When the "Assignee" has done sufficient investigation to determine the cause of the bug or the basic feasibility of implementing the feature. The "Assignee" field may be "null". - Fix in Progress
A solution is available and a BugID is required for push and other tracking activities. An "Assignee" must be identified. - Closed
A bug/RFE may go into one of the following Closed substatuses:- Duplicate
- Future Project
[ new ]
A good idea; however, the implementation is well beyond the scope of anything which may be considered at this time. - Not a Bug
Behavior is as documented or designed. There is little room for misinterpretation. - External [ new ]
Behavior is a bug, however it is not a bug in this Product or any other Product tracked by this bug system. - Not Reproducible
- Will not fix
The IE agrees that this is a problem; however, they have chosen not to fix it. The Evaluation should include reasoning, e.g. not appropriate for the given release, causes unacceptable incompatibilities, etc.)
- Incomplete
More information from the bug/RFE's creator is necessary to evaluate the problem.- A developer must be identified as the "Assignee" as a point of contact for the bug's submitter.
- A description of the required information must be provided in the Evaluation.
Initial triage has determined that the bug/feature request contains sufficient information to estimate the basic feasibility of addressing the problem and to prioritize the request. At this point, the report is assumed to be a real problem. If this is a bug, there is no guarantee that the problem has been reproduced. If it is a feature request, there is no guarantee that the feature will be implemented.
Bugs in this status are owned by the development team responsible for the "Component"/"category/subcategory". A developer will be listed as the "Assignee"/"Responsible Engineer" only if they are actively working on this item or have plans to do so in the immediate future. A bug may be moved out of this status by somebody who has technical depth in the bug's area.
- New [ typical progression ]
- Evaluated
- Fix in Progress
- Closed
- Incomplete
- Evaluated [ typical
progression ]
When a person who has technical depth in the bug's area has done sufficient investigation to determine the cause of the bug or the basic feasibility of implementing the feature. - New
- The bug was misfiled,
- A developer moves this bug to another Category/Subcategory as necessary. The new owning team will triage according to their policies.
- Fix in Progress
- Work on the solution will start.
- An "Assignee" must be identified (if missing).
- The owner knows enough about the potential solution to assign a specific Targeted Pelease. An Evaluation describing the potential solution is provided.
- Closed
[ Same condition as for New. ] - Incomplete
[ Same condition as for New. ]
A developer has performed some investigation to understand the nature of the report and has determined the extent and complexity of the bug and potential fixes.
The following substatus are used to indicate that a certain amount of technical study has been performed.
-
Cause Known
A developer has performed sufficient investigation to gain a basic understanding of how this bug/feature request should be addressed. There is no requirement that an actual solution be known at this time. -
Fix Understood
A developer believes that they have a feasible approach to address the problem. For straight-forward problems, an actual solution may be known. More complex problems may still need additional study to work out the details.
- Open [ typical progression ]
- New
- Fix in Progress
- Closed
- Incomplete
- Fix in Progress
[ Typical progression ]
An "Assignee" has been identified. The owner knows enough about the potential solution to assign a specific Targeted Release and has started working on a solution. - New
[ Same condition as for Open. ] - Open
Further investigation has determined that the originally speculated cause was incorrect or incomplete. - Closed
[ Same condition as for New. ] - Incomplete
[ Same condition as for New. ]
Enough is known about the potential solution to assign a targeted release and the "Assignee" is actively investigating the solution. All bugs which require changes to the Product must explicitly enter this status
Bugs in this status are owned by the development team responsible for the "Component"/"category/subcategory". A developer must be listed as the "Assignee"/"Responsible Engineer". A bug may be moved out of this status as a result of actions by the "Assignee"/"Responsible Engineer".
- Evaluated [ typical progression ]
- New
- Open
- Closed
- Incomplete
- Fixed [ typical progression ]
- For Development, a bug is automatically moved to this status (and "where"
(repositories list is populated) when a Mercurial push with a changeset
comment containing this BugID is detected. Changeset comments may contain
multiple BugIDs.
If the bug is in any other status at the time of "push" an error should occur, preventing the push. Ideally the push will fail if it occurs after the targeted build has been promoted.
Question: If a test is not added or modified as part of this push, should the addition of a "noreg" or "nounit" equivalent be required?
- Changes which do not go to Mercurial repositories may require a manual update.
- For Development, a bug is automatically moved to this status (and "where"
(repositories list is populated) when a Mercurial push with a changeset
comment containing this BugID is detected. Changeset comments may contain
multiple BugIDs.
- Open
You thought you had a solution, but discovered that the real problem was larger or the fix was unacceptable. - Evaluated
If the planned solution is determined to be insufficient to solve the problem and the developer has decided not to further pursue a solution at this time. - Closed
[ Same condition as for New. ] - Incomplete
[ Same condition as for New. ]
A solution (including all code, supporting tests, and documentation) has been delivered to a shared repository and will appear in a promoted build. The solution may need to percolate through one or more repositories before it reaches the one used to create the promotion. As the change is applied to each repository, the "where" list is updated to include that repository.
Bugs in this status are owned by the quality assurance team responsible for the "Component"/"category/subcategory". The "Assignee"/"Responsible Engineer" will be "null" or a member of the quality team. A bug may be moved to Closed by by somebody who is qualified to verify that the issue has been resolved.
Question: If the listed owner is not the person who applied the solution, can the set of all items fixed by a developer be easily identified? An additional "Fixed by" field may be necessary.
- Fix in Progress [ typical progression ]
- Closed
- Verified
[ typical progression ]
Quality has verified that the provided solution has addressed the reported problem. Typically, verification will be via developer-provided regression test passing on all relevant platforms and configurations. - Fix Failed
Quality has verified that a solution was applied, however it did not address the originally reported problem. A new bug must be filed referencing this failed solution. - Unverified
Quality can not verify the solution directly (e.g. unavailable configuration is necessary, bug manifests theoretically, reproduction is difficult, etc.).
- Verified
[ typical progression ]
Terminal status representing two basic types of bugs: Bugs which resulted in changes to the Product (a fix was applied somewhere) and those that did not. Bugs in the latter category can always be re-opened. Bugs in the former can not (at least for JDK Release Projects).
Bugs in this status are effectively owned by the development team responsible for the "Component"/"category/subcategory". The "Assignee"/"Responsible Engineer" will be "null" since no further action is expected to be taken. A bug which has not resulted in a change to the Product may be re-opened or have it's substatus adjusted by a member of the development team.
Development moves bugs into these substatuses. Ideally most bugs which are in these Closed substatuses are moved here during initial triage. No changes to the Product are applied if a bug is in these substatuses. These bugs may be re-opened or have it's substatus adjusted to an alternate non-Product changing substatus.
-
Duplicate
The BugID for the duplicate bug is provided. Key data from the duplicate bug will be copied into the open bug. Data may include, reset of the open bug's Priority, Severity, Keywords, and Customer contact information. -
External [ new ]
Behavior is a bug, however it is not a bug in this Product or any other Product tracked by this Bug System, e.g. a bug in the operating system, hardware, or user application. Advice for reporting this problem to the responsible party should be provided, if possible. If this problem is reported to an external application's bug tracking system, a reference to the report should be added to the Evaluation or Comments. -
Future Project [ new ]
A good idea; however, the implementation is well beyond the scope of anything which may be considered at this time. -
Not a Bug
Behavior is as documented or designed. -
Not Reproducible
An attempt was made to reproduce the problem using information provided, but the problem did not manifest itself or additional data requested to reproduce the problem was not provided. -
Will not Fix
The IE agrees that this is a problem; however, they have chosen not to fix it. The Evaluation should describe why (e.g. not appropriate for the given release, causes unacceptable incompatibilities, problem will be addressed via alternate solution, cost exceeds benefit, etc.)
Quality moves bugs into these substatuses. A change to the Product has been applied; thus, these bugs can not be re-opened (at least for JDK Release Projects).
-
Fix Failed [ new ]
Quality has verified that a solution was applied, however it did not address the originally reported problem. A new bug must be filed referencing this failed solution. -
Unverified [ rare ]
Quality can not verify the solution directly (e.g. unavailable configuration is necessary, but manifests theoretically, reproduction is difficult, etc.). -
Verified
Quality has verified that the provided solution has addressed the reported problem. Typically, verification will be via developer-provided regression test passing on all relevant platforms and configurations.
- Fixed
Typical progression when Product changes are required. - New, Open,
Evaluated,
Fix in Progress [ rare ]
No change to Product is warranted. - Incomplete
- Fix Failed,
Unverified,
Verified
- Terminal status.
- Bugs in these Closed substatuses can ont be re-opened. If the applied change did not address the originally reported problem, a new bug must be filed referencing this bug.
- Duplicate,
Future Project,
Not a Bug,
External,
Not Reproducible,
Will not Fix
- New [ rare ]
- Open [ rare ]
- Evaluated [ rare ]
- Fix in Progress [ rare ]
More information is needed to evaluate the bug or feature request. A description of the required information is provided. The bug submitter is technically responsible for providing this information; however, it may be provided by another interested party. Bugs in this status will time-out after 30 days with an appropriate warning sent to the submitter, the "Assignee", and any watchers.
Bugs in this status are effectively owned by the submitter. The "Assignee"/"Responsible Engineer" will be the individual who requested the additional data. A bug may be moved to Closed: Not Reproducible automatically by the Bug System if additional information is not provided in a timely fashion. Alternatively, the "Assignee" may move the bug to other status based on the provided data.
- New [ typical progression ]
- Open
- Evaluated
- Fix in Progress
- Closed
- New [ typical progression ]
The required information is provided and it is determined that the bug has been misfiled. - Open [ typical progression ]
The required information is provided as requested and the IE confirms that the bug merits further investigation and meets criteria to be Open. Note that "Assignee" may be changed to "null" if there are no immediate plans to address this problem. - Evaluated
The required information is provided and the IE confirms that this bug is something which will be fixed as part of other work currently being conducted (but not quite a duplicate). The "Assignee" may be changed to "null" if there are no immediate plans to address this problem. - Fix in Progress
The required information is provided and the IE determines that a solution has been provided by the submitter or is obvious. An "Assignee" must be identified. - Closed
The required information is provided and the IE determines that the bug can be immediately closed. The "Assignee" is changed to "null".