
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