mirror of
https://github.com/asterisk/asterisk.git
synced 2025-10-31 02:37:10 +00:00
Merge "doxygen: Remove obsolete contents."
This commit is contained in:
Joshua Colp
Gerrit Code Review
@@ -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>
|
||||
*/
|
||||
@@ -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
|
||||
*/
|
||||
@@ -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.
|
||||
*/
|
||||
@@ -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
|
||||
*/
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user