(This document is most beneficial for Asterisk bug marshals, however it is good reading for anyone who may be filing issues or wondering how the Asterisk Open Source project moves issues through from filing to completion.)
The workflow in the issue tracker should be handled in the following way:
The following is a list of valid statuses and what they mean to the work flow.
This issue is awaiting review by bug marshals. Categorization and summaries should be fixed as appropriate.
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. (See https://wiki.asterisk.org/wiki/display/AST/Debugging)
This is a submitted bug which has no patch associated with it, but appears to be a valid bug based on the description and provided debugging information.
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.
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.
A developer or bug marshal 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.
A resolution for this issue has been reached. This issue should immediately be Closed.
No further action is necessary for this issue.
Severity levels generally represent the number of users who are potentially affected by the reported issue.
This issue is a new feature and will only be committed to Asterisk trunk. Asterisk trunk is where future branches will be created and thus this feature will only be found in future branches of Asterisk and not merged into existing branches. (See Release Branch Commit Policy below.)
A trivial issue is something that either affects an insignificant number of Asterisk users, or is a minimally invasive change that does not affect functionality.
A text issue is typically something like a spelling fix, a clarifying of a debugging or verbose message, or changes to documentation.
A tweak to the code the has the potential to either make code clearer to read, or a change that could speed up processing in certain circumstances. These changes are typically only a couple of lines.
An issue that does not affect a large number of Asterisk users, but not an insignificant number. The number of lines of code and development effort to resolve this issue could be non-trivial.
As issue that affects the majority of Asterisk users. The number of lines of code and development effort required to resolve this issue could be non-trivial.
An issue marked as a Crash is something that would cause Asterisk to be unusable for a majority of Asterisk users and is an issue that causes a deadlock or crash of the Asterisk process.
A blocking issue is an issue that must be resolved before the next release of Asterisk as would affect a significant number of Asterisk users, or could be a highly visible regression. A severity of block should only be set by Asterisk bug marshals at their discretion.
*** USERS SHOULD NOT FILE ISSUES WITH A SEVERITY OF BLOCK ***
Currently, the following priority levels are listed on the issue tracker:
However, at this time they are not utilized and all new issue should have a priority of 'Normal'.
The code in the release branches should be changed as little as possible. The only time the release branches will be changed is to fix a bug. New features will never be included in the 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 release branches. Performance issues will only be considered for the 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 release branch, the maintainers should be allowed to make the decision.