[asterisk-dev] [policy] Bug Tracker Workflow Discussion
leif.madsen at asteriskdocs.org
Mon Jul 14 15:42:20 CDT 2008
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 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
> 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
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.
> 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!
More information about the asterisk-dev