
Prev		Next

3. Problem Report State

It is important to update the state of a PR when certain actions are taken. The state should accurately reflect the current state of work on the PR.

Example 1. A small example on when to change PR state

When a PR has been worked on and the developer(s) responsible feel comfortable about the fix, they will submit a followup to the PR and change its state to “feedback”. At this point, the originator should evaluate the fix in their context and respond indicating whether the defect has indeed been remedied.

A Problem Report may be in one of the following states:

open: Initial state; the problem has been pointed out and it needs reviewing.
analyzed: The problem has been reviewed and a solution is being sought.
feedback: Further work requires additional information from the originator or the community; possibly information regarding the proposed solution.
patched: A patch has been committed, but something (MFC, or maybe confirmation from originator) is still pending.
suspended: The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to take on. If the problem cannot be solved at all, it will be closed, rather than suspended. The documentation project uses “suspended” for “wish-list” items that entail a significant amount of work which no one currently has time for.
closed: A problem report is closed when any changes have been integrated, documented, and tested, or when fixing the problem is abandoned.

Note: The “patched” state is directly related to feedback, so you may go directly to “closed” state if the originator cannot test the patch, and it works in your own testing.

Prev	Home	Next
Problem Report Life-cycle		Types of Problem Reports