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 */