From 5d0529c4d9bf662c181d76448e3eadad629e0c71 Mon Sep 17 00:00:00 2001 From: Corey Farrell Date: Fri, 17 Nov 2017 20:54:33 -0500 Subject: doxygen: Remove obsolete contents. Remove doxygen contents that have nothing to do with the current state of Asterisk. Change-Id: Ic072cc8641f9533a202990ccf275ce87e3efd95c --- include/asterisk/doxygen/asterisk-git-howto.h | 235 -------------------- include/asterisk/doxygen/commits.h | 114 ---------- include/asterisk/doxygen/releases.h | 294 -------------------------- include/asterisk/doxygen/reviewboard.h | 125 ----------- include/asterisk/doxyref.h | 6 - 5 files changed, 774 deletions(-) delete mode 100644 include/asterisk/doxygen/asterisk-git-howto.h delete mode 100644 include/asterisk/doxygen/commits.h delete mode 100644 include/asterisk/doxygen/releases.h delete mode 100644 include/asterisk/doxygen/reviewboard.h 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 - * - *
- * - * \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. - *
- * - * \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 - * - *
- * - * \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. - *
- * - * \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 - v1.2.28 v1.2.28.1 - - asterisk$ git show v1.2.28:c - 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 - 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' - # is any place on graph of branches: HEAD, name of a branch or - # a tag, commit ID, and some others - git show # The top commit in this tree (log + diff) - git show :directory # directory listing - git show :some/file # get that file - git log # 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 - * - *
- * - * \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. - * - *
- */ 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 - * - *
- * - * \section CommitMsgFormatting Commit Message Formatting - * - * The following illustrates the basic outline for commit messages: - * - * \verbatim - * - * - * - * - * - * - * - * - * - * \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. - * - *
- * - * \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. - * - *
- * - * \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 None - This release series is receiving no updates whatsoever. - * \arg Security-Only - 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 Full-Support - This release series is receiving updates for all - * types of bugs. - * \arg Full-Development - Changes in this part of Asterisk include bug - * fixes, as well as new %features and architectural improvements. - * - * \section AsteriskReleases Asterisk Maintenance Levels - * - * \htmlonly - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
NameSVN BranchStatusNotes
Asterisk 1.0/branches/1.0None
Asterisk 1.2/branches/1.2Security-Only
Asterisk 1.4/branches/1.4Full-Support
Asterisk 1.6.0/branches/1.6.0Full-Support
Asterisk 1.6.1/branches/1.6.1Full-SupportStill in beta
Asterisk trunk/trunkFull-DevelopmentNo releases are made directly from trunk.
- * \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 - * - *
- * - * \section commitmonitoring Commit Monitoring - * - * To monitor commits to Asterisk and related projects, visit - * http://lists.digium.com. The Digium - * mailing list server hosts a %number of mailing lists for commits. - * - *
- * - * \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. - * - *
- * - * \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 - * Asterisk Security Advisory - * 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 - * - *
- * - * \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. - * - *
- * - * \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 - * mailing list post. - * - * \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. - * - *
- * - * \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. - * - *
- * - * \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 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 - * - *
- * - * \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. - * - *
- * - * \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 - * \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 -- cgit v1.2.3