[Asterisk-code-review] doxygen: Remove obsolete contents. (asterisk[13])
Corey Farrell
asteriskteam at digium.com
Fri Nov 17 19:58:28 CST 2017
Corey Farrell has uploaded this change for review. ( https://gerrit.asterisk.org/7271
Change subject: doxygen: Remove obsolete contents.
......................................................................
doxygen: Remove obsolete contents.
Remove doxygen contents that have nothing to do with the current state
of Asterisk.
Change-Id: Ic072cc8641f9533a202990ccf275ce87e3efd95c
---
D include/asterisk/doxygen/asterisk-git-howto.h
D include/asterisk/doxygen/commits.h
D include/asterisk/doxygen/releases.h
D include/asterisk/doxygen/reviewboard.h
M include/asterisk/doxyref.h
5 files changed, 0 insertions(+), 774 deletions(-)
git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/71/7271/1
diff --git a/include/asterisk/doxygen/asterisk-git-howto.h b/include/asterisk/doxygen/asterisk-git-howto.h
deleted file mode 100644
index 1ecce15..0000000
--- a/include/asterisk/doxygen/asterisk-git-howto.h
+++ /dev/null
@@ -1,235 +0,0 @@
-/*
- * Asterisk -- An open source telephony toolkit.
- *
- * Copyright (C) 1999 - 2009, Digium, Inc.
- *
- * See http://www.asterisk.org for more information about
- * the Asterisk project. Please do not directly contact
- * any of the maintainers of this project for assistance;
- * the project provides a web site, mailing lists and IRC
- * channels for your use.
- *
- * This program is free software, distributed under the terms of
- * the GNU General Public License Version 2. See the LICENSE file
- * at the top of the source tree.
- */
-
-/*!
- * \file
- */
-
-/*!
- * \page AsteriskGitHowto How to setup a local GIT mirror of the Asterisk SVN repository
- *
- * <hr>
- *
- * \section Introduction Introduction
- * This document will instruct you how to setup a local git mirror of the
- * Asterisk SVN repository.
- *
- * Why would you want that? for starters, it's a fast repository browser
- * and works well even when offline. More on why and why not at 'Pros and Cons'
- * in the end of this document.
- * <hr>
- *
- * \section Setup Setup
- *
- * Make sure you have the package
- *
- \verbatim
- git-svn
- \endverbatim
- *
- * installed. It is part of the standard git distribution and included in
- * any recent Linux distribution.
- *
- * Next, get the files from this repository:
- *
- \verbatim
- git clone http://git.tzafrir.org.il/git/asterisk-tools.git
- \endverbatim
- *
- * Which will create the subdirectory 'asterisk-tools' under your working
- * directory. For the purpose of this HOWTO I assume that you will later
- * download Asterisk under the same directory.
- *
- * Now let's get Asterisk:
- *
- \verbatim
- git svn clone -s http://svn.digium.com/svn/asterisk
- \endverbatim
- *
- * This will download the whole /trunk , /tags and /branches hirarchies
- * to a new git repository under asterisk/ .
- * This will take a L O N G time. In the order of magnitude of a
- * day. If it stops in the middle:
- *
- \verbatim
- # cd asterisk; git svn fetch --fetch-all
- \endverbatim
- *
- * All commands as of this point are run from the newly-created subdirectory
- * 'asterisk'
- *
- \verbatim
- cd asterisk
- \endverbatim
- *
- * Next make your repository more compact:
- *
- * \note FIXME: I now get a .git subdirectory of the size of 135MB. This seems
- * overly large considering what I got a few monthes ago.
- *
- \verbatim
- git repack -a
- \endverbatim
- *
- * Now fix the menuselect bits. One possible venue is to use submodules.
- * This would require setting a separate menuselect repository . And
- * fixing the submodule references in every new tag to point to the right
- * place. I gave up at this stage, and instead reimplememented menuselect
- *
- \verbatim
- cp -a ../asterisk-tools/menuselect menuselect
- make -C menuselect dummies
- chmod +x menuselect/menuselect
- \endverbatim
- *
- * Next thing to do is ignore generated files. .gitignore is somewhat
- * like svn:ignore . Though it is possible to use one at the top
- * directory. Hence I decided to make it ignore itself as well:
- *
- \verbatim
- cp ../asterisk-tools/asterisk_gitignore .gitignore
- \endverbatim
- *
- * Now let's generate tags that will point to the tags/* branches.
- * e.g. tag 'v1.4.8' will point to the head of branch tags/1.4.8 .
- * If you don't like the extra 'v', just edit the sed command.
- *
- \verbatim
- ../asterisk-tools/update_tags
- \endverbatim
- *
- * Example configuration (refer to menuselect/menuselelct for more
- * information). For instance: res_snmp breaks building 1.4 from git:
- *
- \verbatim
- echo 'exclude res_snmp' >build_tools/conf
- \endverbatim
- *
- * <hr>
- *
- * \section Update Update
- * The main Asterisk repository tends to get new commits occasionally. I
- * suppose you want those updates in your local copy. The following command
- * should normally be done from the master branch. If you actually use branches,
- * it is recommended to switch to it beforehand:
- *
- \verbatim
- git checkout master
- \endverbatim
- *
- * Next, get all updates.
- * <hr>
- *
- * \section Usage Usage
- *
- * If you use git from the command-line, it is highly recommended to enable
- * programmable bash completion. The git command-line is way more complex
- * than svn, but the completion makes it usable:
- *
- *
- \verbatim
- asterisk$ git show v1.2.28<tab><tab>
- v1.2.28 v1.2.28.1
-
- asterisk$ git show v1.2.28:c<tab><tab>
- callerid.c channel.c cli.c coef_out.h contrib/
- cdr/ channels/ codecs/ config.c cryptostub.c
- cdr.c chanvars.c coef_in.h configs/ cygwin/
-
- asterisk$ git svn<tab><tab>
- clone fetch log set-tree
- commit-diff find-rev propget show-externals
- create-ignore info proplist show-ignore
- dcommit init rebase
-
- asterisk$ git svn rebase --f
- --fetch-all --follow-parent
- \endverbatim
- *
- * Some useful commands:
- *
- \verbatim
- git svn rebase --fetch-all # pull updates from upstream
- man git-FOO # documentation for 'git FOO'
- # <tree> is any place on graph of branches: HEAD, name of a branch or
- # a tag, commit ID, and some others
- git show <tree> # The top commit in this tree (log + diff)
- git show <tree>:directory # directory listing
- git show <tree>:some/file # get that file
- git log <tree> # commit log up to that point
- git branch # shows local branches and in which one you are
- git branch -r # List remote branches. Such are SVN ones.
- \endverbatim
- *
- * For more information, see the man page gittutorial as well as
- * \arg http://git-scm.com/documentation
- *
- \verbatim
- git svn rebase --fetch-all
- \endverbatim
- *
- * <hr>
- *
- * \section ProsAndCons Pros and Cons
- *
- * \subsection TheGood The Good
- *
- * Working off-line:
- * If you want to be able to use 'svn log' and 'svn diff' to a different
- * branch, now you can.
- *
- * Efficient repository browser:
- * With git you can effectively browse commit logs and working copies of
- * various branches. In fact, using it merely as a logs and versions
- * browser can be useful on its own.
- *
- * Branches really work:
- * With SVN merging a branch is complicated. Partially because lack of
- * separate merge tracking.With git you don't need the extra svnmerge:
- * changes that don't collide with your branch merge in a quick merge
- * operation.
- *
- * \subsection Limitations Limitations
- *
- * svn:externals :
- * does not really work well with git-svn (and similar systems: svk,
- * bzr-svn and hg-svn). Git has something called submodules that allows
- * emulating the basic functionality of svn:externals, but is not as
- * transparent.
- *
- * Commiting:
- * Not sure how safe it is to commit from such a copy. In most places I
- * see that it is not recommended to commit directly from git-svn. OTOH,
- * git has some tools that make it easy to prepare a patch set out of a
- * branch (e.g. git format-patch).
- *
- * IIRC there are also some issues for git-svn with https certificate
- * authentication in the first place.
- *
- * Tags:
- * /tags are branches. SVN tags are really branches that we pretend not
- * to change. And in fact in Asterisk we practically do change. But see
- * workaround below to generate tags from the tag branches.
- *
- * /team branches::
- * At least with git 1.5.x you can't easily follow all the team branches.
- * This is due to a bug in their handling of wildcards in branches
- * description. I believe this has been resolved in 1.6 but I didn't get
- * to test that. Even if it will, it will require an extra step of manual
- * editing.
- *
- * <hr>
- */
diff --git a/include/asterisk/doxygen/commits.h b/include/asterisk/doxygen/commits.h
deleted file mode 100644
index 032bfc5..0000000
--- a/include/asterisk/doxygen/commits.h
+++ /dev/null
@@ -1,114 +0,0 @@
-/*
- * Asterisk -- An open source telephony toolkit.
- *
- * Copyright (C) 1999 - 2009, Digium, Inc.
- *
- * See http://www.asterisk.org for more information about
- * the Asterisk project. Please do not directly contact
- * any of the maintainers of this project for assistance;
- * the project provides a web site, mailing lists and IRC
- * channels for your use.
- *
- * This program is free software, distributed under the terms of
- * the GNU General Public License Version 2. See the LICENSE file
- * at the top of the source tree.
- */
-
-/*!
- * \file
- */
-
-/*!
- * \page CommitMessages Guidelines for Commit Messages
- *
- * <hr>
- *
- * \section CommitMsgFormatting Commit Message Formatting
- *
- * The following illustrates the basic outline for commit messages:
- *
- * \verbatim
- * <One-liner summary of changes>
- *
- * <Empty Line>
- *
- * <Verbose description of the changes>
- *
- * <Empty Line>
- *
- * <Special Tags>
- * \endverbatim
- *
- * Some commit history viewers treat the first line of commit messages as the
- * summary for the commit. So, an effort should be made to format our commit
- * messages in that fashion. The verbose description may contain multiple
- * paragraphs, itemized lists, etc. Always end the first sentence (and any
- * subsequent sentences) with punctuation.
- *
- * Commit messages should be wrapped at 80 %columns.
- *
- * \note For trivial commits, such as "fix the build", or "fix spelling mistake",
- * the verbose description may not be necessary.
- *
- * <hr>
- *
- * \section CommitMsgTags Special Tags for Commit Messages
- *
- * \subsection MantisTags Mantis (https://issues.asterisk.org/)
- *
- * To have a commit noted in an issue, use a tag of the form:
- * \arg (issue #1234)
- *
- * To have a commit automatically close an issue, use a tag of the form:
- * \arg (closes issue #1234)
- *
- * When making a commit for a mantis issue, it is easiest to use the
- * provided commit %message template functionality. It will format the
- * special tags appropriately, and will also include information about who
- * reported the issue, which patches are being applied, and who did testing.
- *
- * Assuming that you have bug marshal access (and if you have commit access,
- * it is pretty safe to assume that you do), you will find the commit %message
- * template section directly below the issue details section and above the
- * issue relationships section. You will have to click the '+' next to
- * "Commit message template" to make the contents of the section visible.
- *
- * Here is an example of what the template will generate for you:
- *
- * \verbatim
- * (closes issue #1234)
- * Reported by: SomeGuy
- * Patches:
- * fix_bug_1234.diff uploaded by SomeDeveloper (license 5678)
- * \endverbatim
- *
- * If the patch being committed was written by the person doing the commit,
- * and is not available to reference as an upload to the issue, there is no
- * need to include something like "fixed by me", as that will be the default
- * assumption when a specific patch is not referenced.
- *
- * \subsection ReviewBoardTags Review Board (https://reviewboard.asterisk.org/)
- *
- * To have a commit set a review request as submitted, include the full URL
- * to the review request. For example:
- * \arg Review: %https://reviewboard.asterisk.org/r/95/
- *
- * \note The trailing slash in the review URL is required.
- *
- * <hr>
- *
- * \section CommitMsgSvnmerge Commit Messages with svnmerge
- *
- * When using the svnmerge tool for merging changes between branches, use the
- * commit %message generated by svnmerge. The '-f' option to svnmerge allows
- * you to specify a file for svnmerge to write out a commit %message to. The
- * '-F' option to svn commit allows you to specify a file that contains the
- * commit %message.
- *
- * If you are using the expect script wrappers for svnmerge from repotools,
- * a commit %message is automatically placed in the file '../merge.msg'.
- *
- * For more detailed information about working with branches and merging,
- * see the following page on %asterisk.org:
- * \arg https://wiki.asterisk.org/wiki/display/AST/Subversion+Usage
- */
diff --git a/include/asterisk/doxygen/releases.h b/include/asterisk/doxygen/releases.h
deleted file mode 100644
index d1b33ff..0000000
--- a/include/asterisk/doxygen/releases.h
+++ /dev/null
@@ -1,294 +0,0 @@
-/*
- * Asterisk -- An open source telephony toolkit.
- *
- * Copyright (C) 1999 - 2009, Digium, Inc.
- *
- * See http://www.asterisk.org for more information about
- * the Asterisk project. Please do not directly contact
- * any of the maintainers of this project for assistance;
- * the project provides a web site, mailing lists and IRC
- * channels for your use.
- *
- * This program is free software, distributed under the terms of
- * the GNU General Public License Version 2. See the LICENSE file
- * at the top of the source tree.
- */
-
-/*!
- * \file
- */
-
-/*!
- * \page ReleaseStatus Asterisk Release Status
- *
- * \section warranty Warranty
- * The following warranty applies to all open source releases of Asterisk:
- *
- * NO WARRANTY
- *
- * BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
- * FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
- * OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
- * PROVIDE THE PROGRAM \"AS IS\" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
- * OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
- * TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
- * PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
- * REPAIR OR CORRECTION.
-
- * IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
- * WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
- * REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
- * INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
- * OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
- * TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
- * YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
- * PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
- * POSSIBILITY OF SUCH DAMAGES.
- *
- * \section releasestatustypes Release Status Types
- *
- * Release management is a essentially an agreement between the development
- * community and the %user community on what kind of updates can be expected
- * for Asterisk releases, and what types of changes these updates will contain.
- * Once these policies are established, the development community works very
- * hard to adhere to them. However, the development community does reserve
- * the right to make exceptions to these rules for special cases as the need
- * arises.
- *
- * Asterisk releases are in various states of maintenance. The states are
- * defined here:
- *
- * \arg <b>None</b> - This release series is receiving no updates whatsoever.
- * \arg <b>Security-Only</b> - This release series is receiving updates, but
- * only to address security issues. Security issues found and fixed in
- * this release series will be accompanied by a published security advisory
- * from the Asterisk project.
- * \arg <b>Full-Support</b> - This release series is receiving updates for all
- * types of bugs.
- * \arg <b>Full-Development</b> - Changes in this part of Asterisk include bug
- * fixes, as well as new %features and architectural improvements.
- *
- * \section AsteriskReleases Asterisk Maintenance Levels
- *
- * \htmlonly
- * <table border="1">
- * <tr>
- * <td><b>Name</b></td>
- * <td><b>SVN Branch</b></td>
- * <td><b>Status</b></td>
- * <td><b>Notes</b></td>
- * </tr>
- * <tr>
- * <td>Asterisk 1.0</td>
- * <td>/branches/1.0</td>
- * <td>None</td>
- * </tr>
- * <tr>
- * <td>Asterisk 1.2</td>
- * <td>/branches/1.2</td>
- * <td>Security-Only</td>
- * </tr>
- * <tr>
- * <td>Asterisk 1.4</td>
- * <td>/branches/1.4</td>
- * <td>Full-Support</td>
- * </tr>
- * <tr>
- * <td>Asterisk 1.6.0</td>
- * <td>/branches/1.6.0</td>
- * <td>Full-Support</td>
- * </tr>
- * <tr>
- * <td>Asterisk 1.6.1</td>
- * <td>/branches/1.6.1</td>
- * <td>Full-Support</td>
- * <td>Still in beta</td>
- * </tr>
- * <tr>
- * <td>Asterisk trunk</td>
- * <td>/trunk</td>
- * <td>Full-Development</td>
- * <td>No releases are made directly from trunk.</td>
- * </tr>
- * </table>
- * \endhtmlonly
- *
- * For more information on how and when Asterisk releases are made, see the
- * release policies page:
- * \arg \ref ReleasePolicies
- */
-
-/*!
- * \page ReleasePolicies Asterisk Release and Commit Policies
- *
- * \section releasestatus Asterisk Release Status
- *
- * For more information on the current status of each Asterisk release series,
- * please see the Asterisk Release Status page:
- *
- * \arg \ref ReleaseStatus
- *
- * <hr>
- *
- * \section commitmonitoring Commit Monitoring
- *
- * To monitor commits to Asterisk and related projects, visit
- * <a href="http://lists.digium.com/">http://lists.digium.com</a>. The Digium
- * mailing list server hosts a %number of mailing lists for commits.
- *
- * <hr>
- *
- * \section ast10policy Asterisk 1.0
- *
- * \subsection svnbranch SVN Branch
- *
- * \arg /branches/1.0
- *
- * \subsection ast10releases Release and Commit Policy
- * No more releases of Asterisk 1.0 will be made for any reason.
- *
- * No commits should be made to the Asterisk 1.0 branch.
- *
- * <hr>
- *
- * \section ast12policy Asterisk 1.2
- *
- * \subsection svnbranch SVN Branch
- *
- * \arg /branches/1.2
- *
- * \subsection ast12releases Release and Commit Policy
- *
- * There will be no more scheduled releases of Asterisk 1.2.
- *
- * Commits to the Asterisk 1.2 branch should only address security issues or
- * regressions introduced by previous security fixes. For a security issue, the
- * commit should be accompanied by an
- * <a href="http://downloads.asterisk.org/pub/security/">Asterisk Security Advisory</a>
- * and an immediate release. When a commit goes in to fix a regression, the previous
- * security advisory that is related to the change that introduced the bug should get
- * updated to indicate that there is an updated version of the fix. A release should
- * be made immediately for these regression fixes, as well.
- *
- * \subsection ast12releasenumbers Release Numbering
- *
- * - 1.2.X - a release that contains new security fixes
- * - 1.2.X.Y - a release that contains fixes to the security patches released in
- * version 1.2.X
- *
- * <hr>
- *
- * \section ast14policy Asterisk 1.4
- *
- * \subsection svnbranch SVN Branch
- *
- * \arg /branches/1.4
- *
- * \subsection ast14releases Release and Commit Policy
- *
- * Asterisk 1.4 is receiving regular bug fix release updates. An attempt is made to
- * make releases of every four to six weeks. Since this release series is receiving
- * changes for all types of bugs, the number of changes in a single release can be
- * significant. 1.4.X releases go through a release candidate testing cycle to help
- * catch any regressions that may have been introduced.
- *
- * Commits to Asterisk 1.4 must be to address bugs only. No new %features should be
- * introduced into Asterisk 1.4 to reduce the %number of changes to this established
- * release series. The only exceptions to this %rule are for cases where something
- * that may be considered a feature is needed to address a bug or security issue.
- *
- * \subsection ast14releasenumbers Release Numbering
- *
- * - 1.4.X - a release that contains new bug fixes to the 1.4 release series
- * - 1.4.X.Y - a release that contains very few changes on top of 1.4.X. This
- * may be for a security patch, or for a regression introduced in 1.4.X.
- *
- * <hr>
- *
- * \section ast16policy Asterisk 1.6
- *
- * \subsection svnbranch SVN Branch
- *
- * \arg /branches/1.6.*
- *
- * \subsection ast16releases Release and Commit Policy
- *
- * Asterisk 1.6 is managed in a different way than previous Asterisk release series.
- * From a high level, it was inspired by the release model used for Linux 2.6.
- * The intended time frame for 1.6.X releases is every 2 or 3 months. Each 1.6.X
- * release gets its own branch. The 1.6.X branches are branches off of trunk.
- * Once the branch is created, it only receives bug fixes. Each 1.6.X release goes
- * through a beta and release candidate testing cycle.
- *
- * After a 1.6.X release is published, it will be maintained until 1.6.[X + 3] is
- * released. While a 1.6.X release branch is still maintained, it will receive only
- * bug fixes. Periodic maintenance releases will be made and labeled as 1.6.X.Y.
- * 1.6.X.Y releases should go through a release candidate test cycle before being
- * published.
- *
- * For now, all previous 1.6 release will be maintained for security issues. Once
- * we have more 1.6 releases to deal with, this part of the policy will likely change.
- *
- * For some history on the motivations for Asterisk 1.6 release management, see the
- * first two sections of this
- * <a href="http://lists.digium.com/pipermail/asterisk-dev/2007-October/030083.html">mailing list post</a>.
- *
- * \subsection ast16releasenumbers Release Numbering
- *
- * - 1.6.X - a release that includes new functionality
- * - 1.6.X.Y - a release that contains fixes for bugs or security issues identified
- * in the 1.6.X release series.
- *
- * <hr>
- *
- * \section asttrunk Asterisk Trunk
- *
- * \subsection svnbranch SVN Branch
- *
- * \arg /trunk
- *
- * \subsection asttrunkpolicy Release and Commit Policy
- *
- * No releases are ever made directly from Asterisk trunk.
- *
- * Asterisk trunk is used as the main development area for upcoming Asterisk 1.6
- * releases. Commits to Asterisk trunk are not limited. They can be bug fixes,
- * new %features, and architectural improvements. However, for larger sets
- * of changes, developers should work with the Asterisk project leaders to
- * schedule them for inclusion. Care is taken not to include too many invasive
- * sets of changes for each new Asterisk 1.6 release.
- *
- * No changes should go into Asterisk trunk that are not ready to go into a
- * release. While the upcoming release will go through a beta and release
- * candidate test cycle, code should not be in trunk until the code has been
- * tested and reviewed such that there is reasonable belief that the code
- * is ready to go.
- *
- * <hr>
- *
- * \section astteam Asterisk Team Branches
- *
- * \subsection svnbranch SVN Branch
- *
- * \arg /team/<developername>
- *
- * \subsection astteampolicy Release and Commit Policy
- *
- * The Asterisk subversion repository has a special directory called "team"
- * where developers can make their own personal development branches. This is
- * where new %features, bug fixes, and architectural improvements are developed
- * while they are in %progress.
- *
- * Just about anything goes as far as commits to this area goes. However,
- * developers should keep in mind that anything committed here, as well as
- * anywhere else on Digium's SVN server, falls under the contributor license
- * agreement.
- *
- * In addition to each developer having their own space for working on projects,
- * there is also a team/group folder where %group development efforts take place.
- *
- * Finally, in each developer folder, there is a folder called "private". This
- * is where developers can create branches for working on things that they are
- * not ready for the whole world to see.
- */
diff --git a/include/asterisk/doxygen/reviewboard.h b/include/asterisk/doxygen/reviewboard.h
deleted file mode 100644
index 59ab852..0000000
--- a/include/asterisk/doxygen/reviewboard.h
+++ /dev/null
@@ -1,125 +0,0 @@
-/*
-* Asterisk -- An open source telephony toolkit.
-*
-* Copyright (C) 1999 - 2009, Digium, Inc.
-*
-* See http://www.asterisk.org for more information about
-* the Asterisk project. Please do not directly contact
-* any of the maintainers of this project for assistance;
-* the project provides a web site, mailing lists and IRC
-* channels for your use.
-*
-* This program is free software, distributed under the terms of
-* the GNU General Public License Version 2. See the LICENSE file
-* at the top of the source tree.
-*/
-
-/*!
-* \file
-*/
-
-/*!
- * \page Reviewboard Reviewboard Usage and Guidelines
- *
- * <hr>
- *
- * \section ReviewboardGuidelines Usage Guidelines
- *
- * Mantis (https://issues.asterisk.org) and Reviewboard (https://reviewboard.asterisk.org)
- * are both utilities that the Asterisk development community uses to help
- * track and review code being written for Asterisk. Since both systems
- * are used for posting patches, it is worth discussing when it is appropriate
- * to use reviewboard and when not.
- *
- * Here are the situations in which it is appropriate to post code to reviewboard:
- * - A committer has a patch that they would like to get some feedback on before
- * merging into one of the main branches.
- * - A committer or bug marshal has requested a contributor to post their patch
- * from Mantis on reviewboard to aid in the review process. This typically
- * happens with complex code contributions where reviewboard can help aid in
- * providing feedback.
- *
- * We do encourage all interested parties to participate in the review process.
- * However, aside from the cases mentioned above, we prefer that all code
- * submissions first go through Mantis.
- *
- * \note It is acceptable for a committer to post patches to reviewboard before
- * they are complete to get some feedback on the approach being taken. However,
- * if the code is not yet ready to be merged, it \b must be documented as such.
- * A review request with a patch proposed for merging should have documented
- * testing and should not have blatant coding guidelines violations. Lack of
- * these things is careless and shows disrespect for those reviewing your code.
- *
- * <hr>
- *
- * \section ReviewboardPosting Posting Code to Reviewboard
- *
- * \subsection postreview Using post-review
- *
- * The easiest way to post a patch to reviewboard is by using the
- * post-review tool. We have post-review in our repotools svn repository.
- *
- * \verbatim
- * $ svn co http://svn.digium.com/svn/repotools
- * \endverbatim
- *
- * Essentially, post-review is a script that will take the output of "svn
- * diff" and create a review request out of it for you. So, once you have
- * a working copy with the changes you expect in the output of "svn diff",
- * you just run the following command:
- *
- * \verbatim
- * $ post-review
- * \endverbatim
- *
- * If it complains about not knowing which reviewboard server to use, add
- * the server option:
- *
- * \verbatim
- * $ post-review --server=https://reviewboard.asterisk.org
- * \endverbatim
- *
- * \subsection postreviewnewfiles Dealing with New Files
- *
- * I have one final note about an oddity with using post-review. If you
- * maintain your code in a team branch, and the new code includes new
- * files, there are some additional steps you must take to get post-review
- * to behave properly.
- *
- * You would start by getting your changes applied to a trunk working copy:
- *
- * \verbatim
- * $ cd .../trunk
- * \endverbatim
- *
- * Then, apply the changes from your branch:
- *
- * \verbatim
- * $ svn merge .../trunk .../team/group/my_new_code
- * \endverbatim
- *
- * Now, the code is merged into your working copy. However, for a new
- * file, subversion treats it as a copy of existing content and not new
- * content, so new files don't show up in "svn diff" at this point. To get
- * it to show up in the diff, use the following commands so svn treats it
- * as new content and publishes it in the diff:
- *
- * \verbatim
- * $ svn revert my_new_file.c
- * $ svn add my_new_file.c
- * \endverbatim
- *
- * Now, it should work, and you can run "post-review" as usual.
- *
- * \subsection postreviewupdate Updating Patch on Existing Review Request
- *
- * Most of the time, a patch on reviewboard will require multiple iterations
- * before other sign off on it being ready to be merged. To update the diff
- * for an existing review request, you can use post-review and the -r option.
- * Apply the current version of the diff to a working copy as described above,
- * and then run the following command:
- *
- * \verbatim
- * $ post-review -r <review request number>
- * \endverbatim
- */
diff --git a/include/asterisk/doxyref.h b/include/asterisk/doxyref.h
index 5550023..14ebb4b 100644
--- a/include/asterisk/doxyref.h
+++ b/include/asterisk/doxyref.h
@@ -33,12 +33,6 @@
*
* \section devpolicy Development and Release Policies
* \arg \ref CodeGuide : The must-read document for all developers
- * \arg \ref CommitMessages : Information on formatting and special tags for commit messages
- * \arg \ref ReleaseStatus : The current support level for various Asterisk releases
- * \arg \ref ReleasePolicies : Asterisk Release and Commit Policies
- * \arg \ref Reviewboard : Reviewboard Usage and Guidelines
- * \arg \ref MantisWorkflow : Workflow Guidelines for Asterisk Open Source Issue Tracker
- * \arg \ref AsteriskGitHowto : How to setup a local GIT mirror of the Asterisk SVN repository
* \arg \ref AstCREDITS : A Thank You to contributors (unfortunately out of date)
*
* \section apisandinterfaces Asterisk APIs and Interfaces
--
To view, visit https://gerrit.asterisk.org/7271
To unsubscribe, visit https://gerrit.asterisk.org/settings
Gerrit-Project: asterisk
Gerrit-Branch: 13
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ic072cc8641f9533a202990ccf275ce87e3efd95c
Gerrit-Change-Number: 7271
Gerrit-PatchSet: 1
Gerrit-Owner: Corey Farrell <git at cfware.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20171117/84d5e7b6/attachment-0001.html>
More information about the asterisk-code-review
mailing list