rules/source_repositories -> source_repositories

1 files changed, 2 insertions, 146 deletions

diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn
index 21419393..8215af3b 100644
--- a/rules/source_repositories.mdwn
+++ b/rules/source_repositories.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -9,148 +9,4 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
 is included in the section entitled
 [[GNU Free Documentation License|/fdl]]."]]"""]]
 
-Git repositories on Savannah: <http://git.savannah.gnu.org/cgit/hurd/>.
-
-# Branches
-
-Members of the [[Hurd_Savannah_group|savannah_group]] are allowed to create
-branches without formal permission:
-
-  * named `SAVANNAH_LOGIN/BASE_BRANCH[-TOPIC]` for private general-purpose or
-    topic branches, respectively, or
-  * named `BASE_BRANCH-TOPIC` for public topic branches basing on
-    `BASE_BRANCH`.
-
-`TOPIC` shall be a suitable tag describing the branch's main concern.  These
-tags can be applied recursively (`TOPIC-SUBTOPIC-SUBSUBTOPIC`).
-
-*private* vs. *public* does, of course, in this scenario not mean visibility,
-but instead authority: *private* branches are those that the user
-`SAVANNAH_LOGIN` has authority over, whereas *public* branches are open for
-every committer to install changes on.  The private branches are those that you
-would typically host on your own machine and publish through your own web
-server, but we offer that you can instead do this from the centralized Savannah
-repository, as a number of people don't have an always-accessible web server
-running on their own machines.
-
-Examples:
-
-  * GNU Mach
-
-      * `master` -- the mainline branch
-      * `master-oskit` -- port to OSKit; branched off of `master` at some point
-      * `master-gdb_stubs` -- add support for GDB stubs; branched off of
-        `master` at some point
-
-  * libpthread
-
-      * `master` -- the mainline branch
-      * `master-viengoos` -- port to Viengoos; branched off of `master` at some
-        point
-      * `master-viengoos-on-bare-metal` -- port to Viengoos running on bare
-        metal; branched off of `master-viengoos` at some point
-
-  * unionfs
-
-      * `master` -- the mainline branch
-      * `master-unionmount` -- develop `unionmount` based on `unionfs`' master
-        branch
-
-To give a concrete example, the latter one was created like this:
-
-    $ git clone --no-checkout ssh://git.savannah.gnu.org/srv/git/hurd/unionfs.git
-    $ cd unionfs/
-    $ git checkout -b master-unionmount origin/master
-    $ ...
-    $ git push master-unionmount
-
-## Merging
-
-Merging between Git branches is trivial, at least as long as no conflicts
-arise.
-
-Due to this, you are encouraged to freely make use of separate branches for
-different working topics, as this really faciliates concentrating on one
-specific working topic.
-
-You are encouraged to regularely merge from the respective mainline branches
-(`BASE_BRANCH`; should be `master` in most cases) into your working branches,
-and ensure that your modifications are still fine in the context of new
-mainline changes.
-
-Merging from working branches into the mainline branches will usually be done
-by one of the project administrators, unless negotiated otherwise.  For this to
-happen, the copyright of your changes has to be assigned to the Free Software
-Foundation; read about the
-[[copyright_assignment_process|savannah_group#copyright_assignment]].
-
-It is explicitly encouraged to *merge* changes from working branches into the
-mainline branches (as opposed to *rebase* them on top), as the former mode
-easily allows to determine the context under which a patch has been developed.
-
-# Tags
-
-Equivalent rules apply.
-
-# Behavior
-
-Try to not introduce spurious, unneeded changes, e.g., whitespace changes.
-
-Adhere to the coding conventions that are already used.  These are usually the
-[GNU Coding Standards](http://www.gnu.org/prep/standards/html_node/) for stuff
-written by ourselves, including new files, of course.
-
-GNU Mach code is largely based on external code.  Don't GNU-ify it, as this
-would make merging external patches unnecessarily difficult.
-
-## Commit messages
-
-We no longer maintain parallel `ChangeLog` and commit messages.  When needed,
-the `ChangeLog` files can be created automatically from the commit messages.
-
-Commit messages have this mandatory format:
-
-    One-line summary.
-    Blank line.
-    ChangeLog-like list of changes, but without leading tabs.
-
-The header line of each former `ChangeLog` snippet (DATE NAME EMAIL) is no
-longer to be included in the commit message, and instead the author and
-committer of a change, together with the dates, will be maintained natively by
-Git.
-
-Example:
-
-    commit 3054666a46e0142cacef895c13edb4391435c722
-    Author:     Some One <someone@example.com>
-    AuthorDate: Thu Jun 11 15:59:55 2005 +0000
-    Commit:     Some One <someone@example.com>
-    CommitDate: Thu Jun 11 15:59:55 2005 +0000
-    
-        Frobnicate the foo.
-        
-        * frob.c (foo): Frob it.
-        * oldfoo.c [OLD] (oldfoo): Likewise.
-        [OLD_OLD_FOO] (oofoo): Permute every second word with itself, and
-        beginning with the tenth line, every third one also.  Pure
-        nonsense.
-
-Read about how to write [GNU-style `ChangeLog`
-messages](http://www.gnu.org/prep/standards/html_node/Change-Logs.html).
-
-Don't waste time writing exhaustive `ChangeLog`-like commit messages for, e.g.,
-debugging stuff that will be removed again before merging your development
-branch into the mainline.  Sometimes the one-line summary might already
-suffice.  But please do write something.
-
-## Behavior on *private* branches
-
-Even though you are said to be the owner of branches tagged with your
-`SAVANNAH_LOGIN`, it is generally nevertheless good to not do history-rewriting
-stuff and the like (`git rebase` and friends), as others may in turn be basing
-their work on your private branches.
-
-We could establish a branch-tagging policy for branches that others should
-expect their history possibly to be rewritten.  This may be useful for branches
-that are only meant for aggregating the changes of (several) development
-branches, like an imaginary `master-proposed_for_general_testing` branch.
+[[!meta redir=/source_repositories]]