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(-) 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