From 8f91458f89e13fe5659ac2d5043ad063104d50e4 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 18 Apr 2009 20:51:13 +0200 Subject: rules/source_repositories: Change for CVS to Git conversion. Also add further thoughts (rules, hints, suggestions, whatever). --- rules/source_repositories.mdwn | 114 ++++++++++++++++++++++++----------------- 1 file changed, 66 insertions(+), 48 deletions(-) (limited to 'rules') diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index 2ecc6fe6..7ef19a8b 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[meta copyright="Copyright © 2007, 2008, 2009 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 @@ -8,54 +9,65 @@ 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]]."]]"""]] -CVS repositories on Savannah, see . +Git repositories on Savannah, see (search +for *hurd*). # Branches -Members of the Hurd Savannah group, -, are allowed to -create branches without formal permission... +[Members of the Hurd Savannah +group](http://savannah.gnu.org/project/memberlist.php?group=hurd) are allowed +to create branches without formal permission: -* named *SAVANNAH_LOGIN-WHATEVER-branch* for general-purpose branches, or - -* named *BASE_BRANCH-WHATEVER-branch* for topic-branches basing on + * named *BASE_BRANCH-SAVANNAH_LOGIN[-TOPIC]* for private general-purpose or + topic branches, respectively, or + * named *BASE_BRANCH-TOPIC* for public topic branches basing on *BASE_BRANCH*. -*WHATEVER* shall be a suitable tag. +*TOPIC* shall be a suitable tag describing the branch's main concern. These +tags can be applied recursively (*TOPIC-SUBTOPIC-SUBSUBTOPIC*). -Examples: +*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. -* GNU Mach +Examples: - * *gnumach-1-branch-Xen-branch* - * *gnumach-1-branch-gdb-branch* + * GNU Mach -* GNU Hurd + * *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 - * *miles-orphaned-changes* - * *hammy-libchannel-branch* - * *mmenal-soc2006-nfs-branch* + * libpthread -Also, create helper tags for merging mainline changes into your branches. + * *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 -Examples: - -* GNU Mach +## Merging - * *gnumach-1-branch-Xen-branch*: *gnumach-1-branch-Xen-branch-merge_helper* - * *gnumach-1-branch-gdb-branch*: *gnumach-1-branch-gdb-branch-merge_helper* +Merging between Git branches is trivial, at least as long as no conflicts +arise. -* GNU Hurd +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. - * *hammy-libchannel-branch*: *hammy-libchannel-branch-base* - * *mmenal-soc2006-nfs-branch*: *mmenal-soc2006-nfs-branch-base* +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 - -Merging between CVS branches is not trivial. Unless you really know what -you're doing, please talk to [[Thomas_Schwinge|tschwinge]] or -[[Samuel_Thibault|samuelthibault]], to avoid cluttering the repositories -unintendedly. +Merging from working branches into the mainline branches will usually be done +by one of the project administrators, unless negotiated otherwise. # Tags @@ -63,24 +75,18 @@ Equivalent rules apply. # Behavior -## ... on your branches +## Behavior on branches -Most branches are to be eventually be merged back into the mainline branch. To -faciliate (and also to help other contributors) we'd like you to write a short -summary log in a top-level (or wherever else appropriate) `ChangeLog.WHATEVER` -file. +Usually, branches are to be eventually merged back into their respective +mainline branches. To faciliate (and also to help other contributors) we'd +like you to write a short summary log in a top-level (or wherever else +appropriate) `ChangeLog.*TOPIC*` file. Examples: -* GNU Mach - - * *gnumach-1-branch-Xen-branch*: `ChangeLog.Xen` - * *gnumach-1-branch-gdb-branch-merge_helper*: `ChangeLog.gdb` - -* GNU Hurd + * GNU Mach - * *hammy-libchannel-branch-base*: `channelio/ChangeLog`, `libchannel/ChangeLog` - * *mmenal-soc2006-nfs-branch-base*: `nfs/ChangeLog` + * *master-gdb_stubs*: `ChangeLog.gdb` This need not be a full-fledged [GNU-style *ChangeLog* file](http://www.gnu.org/prep/standards/html_node/Change-Logs.html). E.g., @@ -88,12 +94,24 @@ don't waste time writing *ChangeLog* entries for debugging stuff that will be removed again before merging back into mainline. But please do write something. Short notes. -## ... in general +### 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 *master-proposed_for_general_testing*. + +## Behavior in general Try to not introduce spurious, unneeded changes, e.g., whitespace changes. -Adhere to the already-used coding conventions. These are usually the [GNU -Coding Standards](http://www.gnu.org/prep/standards/html_node/) for stuff +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 -- cgit v1.2.3 From 466e2728e21f9a519c2df5b3bb6f0efa28b1154d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 19 Apr 2009 09:51:29 +0200 Subject: rules/source_repositories: Move a snippet of text to rules/savannah_group. --- rules/savannah_group.mdwn | 5 +++++ rules/source_repositories.mdwn | 5 ++--- 2 files changed, 7 insertions(+), 3 deletions(-) (limited to 'rules') diff --git a/rules/savannah_group.mdwn b/rules/savannah_group.mdwn index 14139719..935a5c87 100644 --- a/rules/savannah_group.mdwn +++ b/rules/savannah_group.mdwn @@ -22,3 +22,8 @@ for sending your contributions, for asking questions, and so on. Have a look at the page for [[contributing]]. Also be sure to have a look at the [[contributing/questionnaire]]. + +## List of members + +The list of members can be seen at +. diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index 7ef19a8b..b84c2145 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -14,9 +14,8 @@ for *hurd*). # Branches -[Members of the Hurd Savannah -group](http://savannah.gnu.org/project/memberlist.php?group=hurd) are allowed -to create branches without formal permission: +Members of the [[Hurd_Savannah_group|savannah_group]] are allowed to create +branches without formal permission: * named *BASE_BRANCH-SAVANNAH_LOGIN[-TOPIC]* for private general-purpose or topic branches, respectively, or -- cgit v1.2.3 From b9c9db8acc47f417ca912d4ec3b3d624cd75493a Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 19 Apr 2009 09:54:47 +0200 Subject: rules/savannah_group: Add stanza about copyright assignments. --- rules/savannah_group.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'rules') diff --git a/rules/savannah_group.mdwn b/rules/savannah_group.mdwn index 935a5c87..ab84e75d 100644 --- a/rules/savannah_group.mdwn +++ b/rules/savannah_group.mdwn @@ -27,3 +27,13 @@ the [[contributing/questionnaire]]. The list of members can be seen at . + + +## Copyright assignment + + +If you have pieces of code or documentation to contribute, then, in order to +install them into our [[source_repositories]], you have to assign the copyright +of your changes to the [Free Software Foundation](http://www.fsf.org/). + +Please [[contact_us]] to request the needed forms. -- cgit v1.2.3 From 6ab6fabb1af5a4b325454acd1f656452ba22ff43 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 19 Apr 2009 10:04:14 +0200 Subject: rules/source_repositories: Add a note about copyright assignment. Suggested by Olaf Buddenhagen. --- rules/source_repositories.mdwn | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'rules') diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index b84c2145..ad488ebf 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -66,7 +66,10 @@ 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. +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]]. # Tags -- cgit v1.2.3 From 6ccb3e0f305bc869c907477b97c95bcbc938bc32 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 29 Apr 2009 10:17:48 +0200 Subject: Reformatting. --- rules/source_repositories.mdwn | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) (limited to 'rules') diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index ad488ebf..044cf6ce 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -17,17 +17,17 @@ for *hurd*). Members of the [[Hurd_Savannah_group|savannah_group]] are allowed to create branches without formal permission: - * named *BASE_BRANCH-SAVANNAH_LOGIN[-TOPIC]* for private general-purpose or + * named `BASE_BRANCH-SAVANNAH_LOGIN[-TOPIC]` for private general-purpose or topic branches, respectively, or - * named *BASE_BRANCH-TOPIC* for public topic branches basing on - *BASE_BRANCH*. + * 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*). +`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 +`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 @@ -38,18 +38,18 @@ 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 + * `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 + * `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 + * `master-viengoos-on-bare-metal` -- port to Viengoos running on bare + metal; branched off of `master-viengoos` at some point ## Merging @@ -61,7 +61,7 @@ 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, +(`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. @@ -82,31 +82,31 @@ Equivalent rules apply. Usually, branches are to be eventually merged back into their respective mainline branches. To faciliate (and also to help other contributors) we'd like you to write a short summary log in a top-level (or wherever else -appropriate) `ChangeLog.*TOPIC*` file. +appropriate) `ChangeLog.TOPIC` file. Examples: * GNU Mach - * *master-gdb_stubs*: `ChangeLog.gdb` + * `master-gdb_stubs`: `ChangeLog.gdb` -This need not be a full-fledged [GNU-style *ChangeLog* +This need not be a full-fledged [GNU-style `ChangeLog` file](http://www.gnu.org/prep/standards/html_node/Change-Logs.html). E.g., -don't waste time writing *ChangeLog* entries for debugging stuff that will be +don't waste time writing `ChangeLog` entries for debugging stuff that will be removed again before merging back into mainline. But please do write something. Short notes. ### 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 +`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 *master-proposed_for_general_testing*. +branches, like `master-proposed_for_general_testing`. ## Behavior in general -- cgit v1.2.3 From 64bc4f0483bc668f5ec0fd85cd39cef80a04131c Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 29 Apr 2009 10:18:48 +0200 Subject: rules/source_repositories: Move a section. --- rules/source_repositories.mdwn | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) (limited to 'rules') diff --git a/rules/source_repositories.mdwn b/rules/source_repositories.mdwn index 044cf6ce..ed09b8c6 100644 --- a/rules/source_repositories.mdwn +++ b/rules/source_repositories.mdwn @@ -77,6 +77,15 @@ 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. + ## Behavior on branches Usually, branches are to be eventually merged back into their respective @@ -107,14 +116,3 @@ 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 `master-proposed_for_general_testing`. - -## Behavior in general - -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. -- cgit v1.2.3