[asterisk-dev] [policy] Bug Tracker Workflow Discussion

[Leif Madsen]

I'm going to be replying inline to the original message I posted. I may 
make some notes regarding the initial description, and if any sort of 
wording needs to be moved to another location.

These are my thoughts on the workflow summary, and encourage anyone to 
comment on them with their own thoughts. Once we determine what the 
status messages will be used for, then we can resolve the wording once 
we agree on what we'll use each status message to mean.

Leif.

Leif Madsen wrote:
> WORKFLOW SUMMARY
> 
> NEW: This issue is awaiting review by bug marshals.  Categorization and
> summaries should be fixed as appropriate.  Initial code review for 
> formatting and coding guidelines issues need to be done.

NEW should be used as the status for bug marshals to indicate that 
initial triage should be performed. This includes verifying the bug is 
not a duplicate, that it is a bug and not a configuration issue, and 
that all required debugging information is present.

Once this is accomplished, the status can be set to 'confirmed' to 
indicate that a developer should continue to move this issue forward.

My thought is that no developers would bother to look at 'new' issues, 
thereby relieving them of excess overhead which can be done by other 
community members who won't be tempted to get involved too heavily with 
the actual resolving of the issue.

Note: I would remove the last sentence and move that to the ACKNOWLEDGED 
workflow status.

> PENDING RELEASE BRANCH: This issue is considered a possible bug in the 
> release branch.  It must be fixed in the release branch if it is 
> appropriate to do so.

PENDING RELEASE BRANCH is probably a defunct workflow type and can 
either be removed, or reserved for future use. This seems to relate back 
to the 1.2 series, which is no longer receiving bug fixes.

> ACKNOWLEGED: This is an issue that only relates to the trunk, but is 
> awaiting initial code review.

ACKNOWLEDGED may also be unnecessary if CONFIRMED will be used to 
identify that initial triage of the issue has been performed by the bug 
marshals.

Perhaps we can utilize the ACKNOWLEDGED workflow status for something in 
between NEW and CONFIRMED?

Is anyone using ACKNOWLEDGED and CONFIRMED, and can explain the 
difference between how you are currently using them?

[some more time elapses]

Thought: Do we need to differentiate between a bug which has debugging 
information (i.e. a backtrace), and a bug which has a patch attached to 
fix the issue?

I'm thinking maybe ACKNOWLEDGED can mean that initial debugging 
information has been attached and is ready for a developer to look at 
the issue. And in the case where [patch] is in the subject header, this 
would mean a developer can look at the issue and perform initial 
formatting and code review.

Once that passes, then the bug would be moved into CONFIRMED status.

 > CONFIRMED: The patch associated with this issue has passed initial
 > formatting and code review and has been tested if needed.  It is
 > awaiting review for inclusion in the trunk.

CONFIRMED would mean that a patch has been supplied, and has passed 
initial formatting and code review. If it has not, then the patch would 
be attached to the bug, the status set to ACKNOWLEDGED, and the subject 
updated to start with [patch] indicating a patch has been supplied which 
may resolve the issue.


> READY FOR TESTING: This is an issue which has a patch that is waiting 
> for testing feedback from the community.

Self explanatory.


> FEEDBACK: This issue requires feedback from the poster of the issue 
> before any additional progress in the workflow can be made. This may 
> include providing additional debugging information, or a backtrace with 
> DONT_OPTIMIZE enabled for example.

Bugs which sit in the FEEDBACK status for more than some given period of 
time (lets say 30 days), should be closed signaling that progress cannot 
be made without the requested information, and that the bug can be 
reopened by a bug marshal in the #asterisk-bugs IRC channel.


> ASSIGNED: A developer or bug marshall has taken responsibility for 
> taking the necessary steps to move forward in the workflow.  Once the 
> issue is ready to be reviewed and feedback provided, it should be placed 
> back into the appropriate place of the workflow.

This is typically used to assign an issue to a particular developer who 
has a good deal of experience in this issue.

> RESOLVED: A resolution for this issue has been reached.  This issue 
> should immediately be CLOSED.

This type may not be necessary anymore as issues can be closed out 
directly from a commit message.

> CLOSED: No further action is necessary for this issue.

Nothing additional from me.



I would appreciate hearing your thoughts!

Thanks!


-- 
Leif Madsen
http://www.leifmadsen.com
http://www.oreilly.com/catalog/asterisk