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 the doc/HOWTO_collect_debug_information.txt file in your 00090 * Asterisk source.) 00091 * 00092 * \subsection Acknowledged 00093 * This is a submitted bug which has no patch associated with it, but appears 00094 * to be a valid bug based on the description and provided debugging 00095 * information. 00096 * 00097 * \subsection Confirmed 00098 * The patch associated with this issue requires initial formatting and code 00099 * review, and may have some initial testing done. It is waiting for a 00100 * developer to confirm the patch will no longer need large changes made to it, 00101 * and is ready for wider testing from the community. This stage is used for 00102 * discussing the feel and style of a patch, in addition to the coding style 00103 * utilized. 00104 * 00105 * \subsection Ready For Testing 00106 * This is an issue which has a patch that is waiting for testing feedback from 00107 * the community after it has been deemed to no longer need larger changes. 00108 * 00109 * \subsection Assigned 00110 * A developer or bug marshal has taken responsibility for taking the necessary 00111 * steps to move forward in the workflow. Once the issue is ready to be 00112 * reviewed and feedback provided, it should be placed back into the 00113 * appropriate place of the workflow. 00114 * 00115 * \subsection Resolved 00116 * A resolution for this issue has been reached. This issue should immediately 00117 * be Closed. 00118 * 00119 * \subsection Closed 00120 * No further action is necessary for this issue. 00121 * 00122 * \section SeverityLevels Severity Levels 00123 * 00124 * Severity levels generally represent the number of users who are potentially 00125 * affected by the reported issue. 00126 * 00127 * \subsection Feature Feature 00128 * This issue is a new feature and will only be committed to Asterisk trunk. 00129 * Asterisk trunk is where future branches will be created and thus this 00130 * feature will only be found in future branches of Asterisk and not merged 00131 * into existing branches. (See Release Branch Commit Policy below.) 00132 * 00133 * \subsection Trivial Trivial 00134 * A trivial issue is something that either affects an insignificant number of 00135 * Asterisk users, or is a minimally invasive change that does not affect 00136 * functionality. 00137 * 00138 * \subsection Text Text 00139 * A text issue is typically something like a spelling fix, a clarifying of a 00140 * debugging or verbose message, or changes to documentation. 00141 * 00142 * \subsection Tweak Tweak 00143 * A tweak to the code the has the potential to either make code clearer to 00144 * read, or a change that could speed up processing in certain circumstances. 00145 * These changes are typically only a couple of lines. 00146 * 00147 * \subsection Minor Minor 00148 * An issue that does not affect a large number of Asterisk users, but not an 00149 * insignificant number. The number of lines of code and development effort to 00150 * resolve this issue could be non-trivial. 00151 * 00152 * \subsection Major Major 00153 * As issue that affects the majority of Asterisk users. The number of lines of 00154 * code and development effort required to resolve this issue could be 00155 * non-trivial. 00156 * 00157 * \subsection Crash Crash 00158 * An issue marked as a Crash is something that would cause Asterisk to be 00159 * unusable for a majority of Asterisk users and is an issue that causes a 00160 * deadlock or crash of the Asterisk process. 00161 * 00162 * \subsection Block Block 00163 * A blocking issue is an issue that must be resolved before the next release 00164 * of Asterisk as would affect a significant number of Asterisk users, or could 00165 * be a highly visible regression. A severity of block should only be set by 00166 * Asterisk bug marshals at their discretion. 00167 * 00168 * *** USERS SHOULD NOT FILE ISSUES WITH A SEVERITY OF BLOCK *** 00169 * 00170 * \section PriorityLevels Priority Levels 00171 * 00172 * Currently, the following priority levels are listed on the issue tracker: 00173 * - None 00174 * - Low 00175 * - Normal 00176 * - High 00177 * - Urgent 00178 * - Immediate 00179 * 00180 * However, at this time they are not utilized and all new issue should have a priority of 'Normal'. 00181 * 00182 * \section Notes Notes 00183 * 00184 * -# Using the "Need Triage" filter is useful for finding these issues quickly. 00185 * -# The issue tracker now has the ability to monitor the commits list, and if 00186 * the commit message contains something like, "(Closes issue #9999)", the bug 00187 * will be automatically closed.\n 00188 * See http://www.asterisk.org/doxygen/trunk/CommitMessages.html for more 00189 * information on commit messages. 00190 * 00191 * \section ReleaseBranchCommitPolicy Release Branch Commit Policy 00192 * 00193 * The code in the release branches should be changed as little as possible. The 00194 * only time the release branches will be changed is to fix a bug. New features 00195 * will never be included in the release branch unless a special exception is made 00196 * by the release branch maintainers. 00197 * 00198 * Sometimes it is difficult to determine whether a patch is considered to fix a 00199 * bug or if it is a new feature. Patches that are considered code cleanup, or to 00200 * improve performance, are NOT to be included in the release branches. Performance 00201 * issues will only be considered for the release branch if they are considered 00202 * significant, and should be approved by the maintainers. 00203 * 00204 * If there is ever a question about what should be included in the release branch, 00205 * the maintainers should be allowed to make the decision. 00206 */