summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@schwinge.name>2010-02-27 21:38:14 +0100
committerThomas Schwinge <thomas@schwinge.name>2010-02-27 21:38:14 +0100
commita470fa9bd3224186c4a79db5bc386883f661abd0 (patch)
tree65b6aa9a80e4bae5ce20a35312b7646dad077f30
parenta3e20e0c3f2012ab580cf4118259da68668a5812 (diff)
rules/source_repositories -> source_repositories
-rw-r--r--rules/source_repositories.mdwn148
-rw-r--r--source_repositories.mdwn156
2 files changed, 158 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]]
diff --git a/source_repositories.mdwn b/source_repositories.mdwn
new file mode 100644
index 00000000..fc52714e
--- /dev/null
+++ b/source_repositories.mdwn
@@ -0,0 +1,156 @@
+[[!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]]."]]"""]]
+
+Git repositories on Savannah: <http://git.savannah.gnu.org/cgit/hurd/>.
+
+# Branches
+
+Members of the [[Hurd Savannah group|rules/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|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 `master-proposed_for_general_testing` branch.