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

[Leif Madsen]

Based on the feedback received in this thread so far, here is an updated 
version of the bug status guidelines. Please continue to review, and 
thank you for the feedback!

Note: I have not updated the RESOLVED status based on Jay's feedback 
yet. I do believe his suggestion to wait for either:

a) the original poster to acknowledge that the issue has been resolved 
and that the bug can be closed

- or -

b) that a period of time (to be determined, most likely 1-2 weeks) has 
elapsed without a response, that the issue can be closed.

...will be done, but until the scripts that automatically close the bugs 
are updated, then I will leave the description for now.

Thanks!
Leif Madsen.

~~~~~~~~~~~~~~~~~~~~~~~~~~

BUG TRACKER WORKFLOW

The workflow in the bug tracker should be handled in the following way:

1) A bug is reported and is automatically placed in the 'new' status.[Note1]

2) The Bug Marshall team should go through bugs in the 'new' status to 
determine whether the report is valid (not a duplicate, hasn't already 
been fixed, not a Digium tech support issue, etc.).  Invalid reports 
should be set to 'closed' with the appropriate resolution.  Categories 
and descriptions should be corrected at this point.[Note2]

3) The next step is to determine whether the report is about a bug or a 
submission of a new feature. Note that not all bugs will follow this 
entire workflow, as some bugs may be resolved by a developer and closed 
out immediately; i.e. when a trivial bug is found and resolved.

      a) BUG: A bug should be moved into the status 'acknowledged' after 
the initial triage has been performed. Initial triage includes, but is 
not limited to, obtaining a description of how to recreate the bug, 
appropriate logs and traces, and any additional information required by 
a developer in order to solve the issue. The bug may flip between 'new' 
and 'feedback' statuses several times until the required information is 
obtained before moving to 'acknowledged'.

       The bug may also be assigned to a developer for the creation of 
the initial patch, or review of the issue. Once a patch has been created 
for the issue and attached, the issue can then be moved to the 
'confirmed' status. At this point initial code review and discussion 
about the patch will take place. Once an adequate amount of support for 
the implementation of the patch is acquired, then the bug can be moved 
to the 'ready for testing' status for wider testing by the community. 
After the testing phase is complete and it appears the issue is 
resolved, the patch can be committed by a developer and closed.

      b) FEATURE: As new features should be filed with a patch, it can 
be immediately moved to the 'confirmed' status, making it ready for 
basic formatting and code review. From there any changes to style or 
feel of the patch based on feedback from the community can be discussed, 
and changes to the patch made. It can then be moved forward to the 
'ready for testing' status. Once the feature has been merged, or a 
decision has been made that it will not be merged, the issue should be 
taken to 'closed' with the appropriate resolution.[Note3]

4) If at any point in the workflow, an issue requires feedback from the 
original poster of the issue, the status should be changed to 
'feedback'.  Once the required information has been provided, it should 
be placed back in the appropriate point of the workflow.[Note4]

5) If at any point in the workflow, a developer or bug marshall would 
like to take responsibility for doing the work that is necessary to 
progress an issue, the status can be changed to 'assigned'.  Once these 
changes have been completed, it can be placed back in the appropriate 
place in the workflow.

WORKFLOW SUMMARY

NEW: This issue is awaiting review by bug marshals. Categorization and 
summaries should be fixed as appropriate. Initial triage should be done 
to verify enough information in the form of a description, logs, traces, 
etc... are available to the bug marshals.


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. Once the bug is moved to the 
feedback status, it will not be automatically moved out of this status, 
thus it is the responsibility of the bug marshals to monitor and move 
issues out of feedback status into the appropriate workflow when necessary.


ACKNOWLEGED: This is a submitted bug which has no patch associated with 
it, but appears to be a valid bug based on the description. Enough 
triage should already performed to collect the descriptions of how to 
reproduce the bug, logs, traces, etc... before moving to this status.


CONFIRMED: The patch associated with this issue requires initial 
formatting and code review, and may have some initial testing done. It 
is waiting for a developer to confirm the patch will no longer need 
large changes made to it, and is ready for wider testing from the 
community. This stage is used for discussing the feel and style of a 
patch, in addition to the coding style utilized.


READY FOR TESTING: This is an issue which has a patch that is waiting 
for testing feedback from the community after it has been deemed to no 
longer need larger changes.


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.


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


CLOSED: No further action is necessary for this issue.

PENDING RELEASE BRANCH: This status is no longer used. It is a relic of 
the Asterisk 1.2 days.

Notes:


1) Certain categories are automatically assigned to developers. In these 
cases, those developers will be responsible initially moving the bug 
through the workflow process.

2) Using the "New / Uncommented" filter is useful for finding these 
issues quickly.

3) The bug tracker now has the ability to monitor the commits list, and 
if the commit message contains something like, "closes issue #9999", the 
bug will be automatically closed.

4) Since this is not automatic, bug marshals will need to monitor the 
issues in 'feedback' in order to make sure bugs are placed back into the 
appropriate place in the workflow. This can be accomplished using the 
filtering system.

1.4 RELEASE BRANCH COMMIT POLICY

The code in the 1.4 release branch should be changed as little as 
possible.  The only time the 1.4 release branch will be changed is to 
fix a bug.  New features will never be included in the 1.4 release 
branch unless a special exception is made by the release branch maintainers.

Sometimes it is difficult to determine whether a patch is considered to 
fix a bug or if it is a new feature.  Patches that are considered code 
cleanup, or to improve performance, are NOT to be included in the 1.4 
release branch.  Performance issues will only be considered for the 1.4 
release branch if they are considered significant, and should be 
approved by the maintainers.

If there is ever a question about what should be included in the 1.4 
release branch, the maintainers should be allowed to make the decision. 
Currently the branch maintainer is Russell Bryant.