Merge branch 'master' into external_pager_mechanism

Conflicts:
	microkernel/mach/external_pager_mechanism.mdwn

1 files changed, 257 insertions, 0 deletions

diff --git a/source_repositories.mdwn b/source_repositories.mdwn
new file mode 100644
index 00000000..610bc01b
--- /dev/null
+++ b/source_repositories.mdwn
@@ -0,0 +1,257 @@
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation,
+Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+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]]."]]"""]]
+
+This page is meant to give some guidelines.  Please use good sense or ask on
+[[mailing_lists/bug-hurd]] if there are any questions.
+
+
+[[!toc levels=3]]
+
+
+# Git repositories on Savannah
+
+<http://git.savannah.gnu.org/cgit/hurd>
+
+  * hurd.git -- Hurd meta package; no real content yet
+  * [[hurd/glibc.git|glibc]] -- [[/glibc]] maintenance
+  * hurd/gnumach.git -- [[GNU Mach|microkernel/mach/gnumach]]
+  * hurd/hurd.git -- [[/Hurd]]
+  * [[hurd/incubator.git|incubator]] -- the great next stuff
+  * hurd/libpthread.git	-- [[POSIX threading library|libpthread]]
+  * hurd/mig.git -- [[microkernel/mach/MIG]]
+  * hurd/procfs.git -- [[hurd/translator/procfs]]
+  * hurd/unionfs.git --  -- [[hurd/translator/unionfs]]
+  * hurd/viengoos.git  -- [[microkernel/Viengoos]]
+  * hurd/web.git -- [[contributing/Web_pages]]
+
+
+## Branches
+
+Members of the [[Hurd Savannah group|rules/savannah group]] are allowed to create
+branches without formal permission:
+
+  * named `SAVANNAH_LOGIN/BASE_BRANCH[-TOPIC]` or
+    `SAVANNAH_LOGIN/TOPIC/BASE_BRANCH` for private general-purpose or
+    topic branches, respectively, or
+  * named `BASE_BRANCH-TOPIC` or `TOPIC/BASE_BRANCH` 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/BASE_BRANCH`, like
+`pfinet_rewrite/use_lwIP/master`, for example).
+
+*private* vs. *public* does, of course, in this scenario not mean visibility
+(all branches are externally visible),
+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.
+
+
+### Subprojects
+
+Some repositories hold a bunch of independent subprojects, first and foremost
+the [[incubator]] repository.
+
+Even though we've been doing differently in the past, branches in there shall
+be named like this:
+
+  * `SUBPROJECT/master` for the `master` branch;
+  * `SUBPROJECT/SAVANNAH_LOGIN/BASE_BRANCH[-TOPIC]` or
+    `SUBPROJECT/SAVANNAH_LOGIN/TOPIC/BASE_BRANCH` for private general-purpose
+    or topic branches, respectively, or
+  * `SUBPROJECT/BASE_BRANCH-TOPIC` or `SUBPROJECT/TOPIC/BASE_BRANCH` for public
+    topic branches basing on `SUBPROJECT/BASE_BRANCH`.
+
+That is, we introduce a top-level `SUBPROJECT` hierarchy, where distinct
+per-subproject Git repositories could have been used instead.
+
+
+### 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
+
+  * incubator
+
+      * `master` -- not to be used
+      * `tarfs/master` -- `master` branch of the `tarfs` subproject
+
+  * 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|rules/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
+`rewrite_pfinet/for_master_and_proposed_for_general_testing` branch.
+
+
+# Git repositories on flubber
+
+[[flubber|public hurd boxen]] is
+[[configured|public_hurd_boxen/installation/flubber]] in a way so that users
+can publish Git repositories from their home directories.  The only thing to do
+is to put an empty `.git/git-daemon-export-ok` (cf. [*git daemon*'s manual
+page](http://www.kernel.org/pub/software/scm/git/docs/git-daemon.html)) into
+the repository, or just `git-daemon-export-ok` for
+[*bare*](http://www.kernel.org/pub/software/scm/git/docs/git-init.html)
+repositories.
+
+For example, the [[contributing/web pages]] repository is made available like
+this: `~hurd-web/hurd-web` is a bare repository; there is an empty
+`~hurd-web/hurd-web/git-daemon-export-ok` file.  Users can clone the repository
+like this:
+
+    $ git clone git://flubber.bddebian.com/~hurd-web/hurd-web
+
+Another example, [[Thomas Schwinge|tschwinge]] has a checkout of
+[[libpthread]] in `~tschwinge/tmp/hurd/libpthread/`, the
+`~tschwinge/tmp/hurd/libpthread/.git/git-daemon-export-ok` file exists.  If you
+really need to, you can clone it like this:
+
+    $ git clone git://flubber.bddebian.com/~tschwinge/tmp/hurd/libpthread
+
+## List of Interesting Repositories
+
+  * web pages: git://flubber.bddebian.com/~hurd-web/hurd-web
+
+
+# Git repositories on grubber
+
+## List of Interesting Repositories
+
+  * [[binutils]]
+  * [[Boehm_GC]]
+  * [[GCC]]
+
+
+# Debian Git repositories
+
+IRC, #hurd, 2010-07-31
+
+    <tschwinge> git-buildpackage is to be used to build these new Debian repositories, I guess?
+    <youpi> well, the Vcs-Git control header is about everything people need to know, I believe :)
+    <youpi> git-buildpackage is just mostly an easy way to build the .orig.tar.Gz from the tag
+    <youpi> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html