Merge "doxygen: Remove obsolete contents." into 15

5 files changed, 0 insertions, 774 deletions

diff --git a/include/asterisk/doxygen/asterisk-git-howto.h b/include/asterisk/doxygen/asterisk-git-howto.h
deleted file mode 100644
index 1ecce15c0..000000000
--- 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 032bfc5f4..000000000
--- 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 d1b33ffd2..000000000
--- 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/&lt;developername&gt;
- *
- * \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 59ab852bd..000000000
--- 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 55500230d..14ebb4b83 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