Sat Mar 10 01:54:20 2012

Asterisk developer's documentation


mantisworkflow.h

Go to the documentation of this file.
00001 /*
00002  * Asterisk -- An open source telephony toolkit.
00003  *
00004  * Copyright (C) 1999 - 2009, Digium, Inc.
00005  *
00006  * See http://www.asterisk.org for more information about
00007  * the Asterisk project. Please do not directly contact
00008  * any of the maintainers of this project for assistance;
00009  * the project provides a web site, mailing lists and IRC
00010  * channels for your use.
00011  *
00012  * This program is free software, distributed under the terms of
00013  * the GNU General Public License Version 2. See the LICENSE file
00014  * at the top of the source tree.
00015  */
00016 
00017 /*!
00018  * \file
00019  */
00020 
00021 /*!
00022  * \page MantisWorkflow Workflow Guidelines for Asterisk Open Source Issue Tracker
00023  *
00024  * \AsteriskTrunkWarning
00025  *
00026  * <hr/>
00027  * \section WorkflowDescription Description of the Issue Tracker Workflow
00028  * 
00029  * (This document is most beneficial for Asterisk bug marshals, however it is good
00030  * reading for anyone who may be filing issues or wondering how the Asterisk Open
00031  * Source project moves issues through from filing to completion.)
00032  * 
00033  * The workflow in the issue tracker should be handled in the following way:
00034  * 
00035  * -# A bug is reported and is automatically placed in the 'New' status.
00036  * -# The Bug Marshall team should go through bugs in the 'New' status to determine 
00037  *    whether the report is valid (not a duplicate, hasn't already been fixed, not 
00038  *    a Digium tech support issue, etc.).  Invalid reports should be set to 
00039  *    'Closed' with the appropriate resolution set. Categories and descriptions 
00040  *    should be corrected at this point.[Note1]\n
00041  *    Issues should also have enough information for a developer to either 
00042  *    reproduce the issue or determine where an issue exists (or both). If this is 
00043  *    not the case then the issue should be moved to 'Feedback' prior to moving 
00044  *    forward in the workflow.
00045  * -# The next step is to determine whether the report is about a bug or a 
00046  *    submission of a new feature:
00047  *       -# BUG: A bug should be moved into the status 'Acknowledged' if enough
00048  *          information has been provided by the reporter to either reproduce the
00049  *          issue or clearly see where an issue may lie. The bug may also be
00050  *          assigned to a developer for the creation of the initial patch, or
00051  *          review of the issue.\n
00052  *          Once a patch has been created for the issue and attached, the issue can
00053  *          then be moved to the 'Confirmed' status. At this point, initial code 
00054  *          review and discussion about the patch will take place. Once an adequate
00055  *          amount of support for the implementation of the patch is acquired, then
00056  *          the bug can be moved to the 'Ready for Testing' status for wider 
00057  *          testing by the community. After the testing phase is complete and it
00058  *          appears the issue is resolved, the patch can be committed by a 
00059  *          developer and closed.
00060  *       -# FEATURE: As new features should be filed with a patch, it can be 
00061  *          immediately moved to the 'confirmed' status, making it ready for basic
00062  *          formatting and code review. From there any changes to style or feel of
00063  *          the patch based on feedback from the community can be discussed, and
00064  *          changes to the patch made. It can then be moved forward to the 'Ready 
00065  *          for Testing' status. Once the feature has been merged, or a decision
00066  *          has been made that it will not be merged, the issue should be taken to 
00067  *          'Closed' with the appropriate resolution.[Note2]
00068  * -# If at any point in the workflow, an issue requires feedback from the original
00069  *    poster of the issue, the status should be changed to 'Feedback'.  Once the 
00070  *    required information has been provided, it should be placed back in the
00071  *    appropriate point of the workflow.
00072  * -# If at any point in the workflow, a developer or bug marshal would like to 
00073  *    take responsibility for doing the work that is necessary to progress an 
00074  *    issue, the status can be changed to 'Assigned'. At that point the developer
00075  *    assigned to the issue will be responsible for moving the issue to completion.
00076  * 
00077  * \section WorkflowSummary Workflow Summary
00078  * 
00079  * The following is a list of valid statuses and what they mean to the work flow.
00080  *
00081  * \subsection New New
00082  *    This issue is awaiting review by bug marshals.  Categorization and summaries
00083  *    should be fixed as appropriate.
00084  * 
00085  * \subsection Feedback
00086  *    This issue requires feedback from the poster of the issue before any
00087  *    additional progress in the workflow can be made. This may include providing
00088  *    additional debugging information, or a backtrace with DONT_OPTIMIZE enabled,
00089  *    for example. (See https://wiki.asterisk.org/wiki/display/AST/Debugging)
00090  * 
00091  * \subsection Acknowledged
00092  *    This is a submitted bug which has no patch associated with it, but appears
00093  *    to be a valid bug based on the description and provided debugging
00094  *    information.
00095  * 
00096  * \subsection Confirmed
00097  *    The patch associated with this issue requires initial formatting and code
00098  *    review, and may have some initial testing done. It is waiting for a 
00099  *    developer to confirm the patch will no longer need large changes made to it,
00100  *    and is ready for wider testing from the community. This stage is used for
00101  *    discussing the feel and style of a patch, in addition to the coding style
00102  *    utilized.
00103  * 
00104  * \subsection Ready For Testing
00105  *    This is an issue which has a patch that is waiting for testing feedback from
00106  *    the community after it has been deemed to no longer need larger changes.
00107  * 
00108  * \subsection Assigned
00109  *    A developer or bug marshal has taken responsibility for taking the necessary
00110  *    steps to move forward in the workflow.  Once the issue is ready to be
00111  *    reviewed and feedback provided, it should be placed back into the
00112  *    appropriate place of the workflow.
00113  * 
00114  * \subsection Resolved
00115  *    A resolution for this issue has been reached.  This issue should immediately
00116  *    be Closed.
00117  * 
00118  * \subsection Closed
00119  *    No further action is necessary for this issue.
00120  * 
00121  * \section SeverityLevels Severity Levels
00122  * 
00123  * Severity levels generally represent the number of users who are potentially
00124  * affected by the reported issue. 
00125  * 
00126  * \subsection Feature Feature
00127  *    This issue is a new feature and will only be committed to Asterisk trunk.
00128  *    Asterisk trunk is where future branches will be created and thus this
00129  *    feature will only be found in future branches of Asterisk and not merged
00130  *    into existing branches. (See Release Branch Commit Policy below.)
00131  * 
00132  * \subsection Trivial Trivial
00133  *    A trivial issue is something that either affects an insignificant number of
00134  *    Asterisk users, or is a minimally invasive change that does not affect
00135  *    functionality.
00136  * 
00137  * \subsection Text Text
00138  *    A text issue is typically something like a spelling fix, a clarifying of a
00139  *    debugging or verbose message, or changes to documentation.
00140  * 
00141  * \subsection Tweak Tweak
00142  *    A tweak to the code the has the potential to either make code clearer to
00143  *    read, or a change that could speed up processing in certain circumstances.
00144  *    These changes are typically only a couple of lines.
00145  * 
00146  * \subsection Minor Minor
00147  *    An issue that does not affect a large number of Asterisk users, but not an
00148  *    insignificant number. The number of lines of code and development effort to
00149  *    resolve this issue could be non-trivial.
00150  * 
00151  * \subsection Major Major
00152  *    As issue that affects the majority of Asterisk users. The number of lines of
00153  *    code and development effort required to resolve this issue could be
00154  *    non-trivial.
00155  * 
00156  * \subsection Crash Crash
00157  *    An issue marked as a Crash is something that would cause Asterisk to be
00158  *    unusable for a majority of Asterisk users and is an issue that causes a
00159  *    deadlock or crash of the Asterisk process.
00160  * 
00161  * \subsection Block Block
00162  *    A blocking issue is an issue that must be resolved before the next release
00163  *    of Asterisk as would affect a significant number of Asterisk users, or could
00164  *    be a highly visible regression. A severity of block should only be set by
00165  *    Asterisk bug marshals at their discretion.
00166  * 
00167  *        *** USERS SHOULD NOT FILE ISSUES WITH A SEVERITY OF BLOCK ***
00168  * 
00169  * \section PriorityLevels Priority Levels
00170  *
00171  * Currently, the following priority levels are listed on the issue tracker:
00172  * - None
00173  * - Low
00174  * - Normal
00175  * - High
00176  * - Urgent
00177  * - Immediate
00178  *
00179  * However, at this time they are not utilized and all new issue should have a priority of 'Normal'.
00180  *
00181  * \section Notes Notes
00182  * 
00183  * -# Using the "Need Triage" filter is useful for finding these issues quickly.
00184  * -# The issue tracker now has the ability to monitor the commits list, and if
00185  *    the commit message contains something like, "(Closes issue #9999)", the bug
00186  *    will be automatically closed.\n
00187  *    See http://www.asterisk.org/doxygen/trunk/CommitMessages.html for more
00188  *    information on commit messages.
00189  * 
00190  * \section ReleaseBranchCommitPolicy Release Branch Commit Policy
00191  * 
00192  * The code in the release branches should be changed as little as possible.  The 
00193  * only time the release branches will be changed is to fix a bug.  New features 
00194  * will never be included in the release branch unless a special exception is made
00195  * by the release branch maintainers.
00196  * 
00197  * Sometimes it is difficult to determine whether a patch is considered to fix a 
00198  * bug or if it is a new feature.  Patches that are considered code cleanup, or to 
00199  * improve performance, are NOT to be included in the release branches. Performance
00200  * issues will only be considered for the release branch if they are considered 
00201  * significant, and should be approved by the maintainers.
00202  * 
00203  * If there is ever a question about what should be included in the release branch,
00204  * the maintainers should be allowed to make the decision.
00205  */

Generated on Sat Mar 10 01:54:20 2012 for Asterisk - The Open Source Telephony Project by  doxygen 1.4.7