[cp-patches] FYI: Add branch "rules" to hacking guide

[Mark Wielaard]

Hi,

This adds the branch rules we discussed on the main list to the Hacking
Guide.

2005-12-11  Mark Wielaard  <address@hidden>

        * doc/hacking.texinfo: Add section on branches.

I also added a page to the developer wiki to document all branches:
http://developer.classpath.org/mediation/ClasspathBranches

Committed,

Mark

Index: hacking.texinfo
===================================================================
RCS file: /cvsroot/classpath/classpath/doc/hacking.texinfo,v
retrieving revision 1.38
diff -u -r1.38 hacking.texinfo
--- hacking.texinfo     15 Jul 2005 08:54:10 -0000      1.38
+++ hacking.texinfo     11 Dec 2005 21:27:18 -0000
@@ -83,6 +83,11 @@
 
 Working on the code, Working with others
 
+* Branches::                    
+* Writing ChangeLogs::          
+
+Working with branches
+
 * Writing ChangeLogs::          
 
 Programming Goals
@@ -807,10 +812,68 @@
 constraints).
 
 @menu
+* Branches::                    
+* Writing ChangeLogs::          
address@hidden menu
+
address@hidden Branches, Writing ChangeLogs, Hacking Code, Hacking Code
address@hidden node-name, next, previous, up
address@hidden Working with branches
+
+Sometimes it is necessary to create branch of the source for doing new
+work that is disruptive to the other hackers, or that needs new
+language or libraries not yet (easily) available.
+
+After discussing the need for a branch on the main mailinglist with
+the other hackers explaining the need of a branch and suggestion of
+the particular branch rules (what will be done on the branch, who will
+work on it, will there be different commit guidelines then for the
+mainline trunk and when is the branch estimated to be finished and
+merged back into the trunk) every GNU Classpath hacker with commit
+access should feel free to create a branch. There are however a couple
+of rules that every branch should follow:
+
address@hidden
+
address@hidden All branches ought to be documented in the developer wiki at
address@hidden://developer.classpath.org/mediation/ClasspathBranches}, so
+we can know which are live, who owns them, and when they die.
+
address@hidden Some rules can be changed on a branch.  In particular the branch
+maintainer can change the review requirements, and the requirement of
+keeping things building, testing, etc, can also be lifted.  (These
+should be documented along with the branch name and owner if they
+differ from the trunk.)
+
address@hidden Requirements for patch email to classpath-patches and for 
paperwork
address@hidden be lifted. See @ref{Requirements}.
+
address@hidden A branch should not see it as ``private'' or
+``may be broken at random times''. It should be as much as possible
+something that you work on with a team (and if there is no team - yet
+- then there is nothing as bad as having a completely broken build to
+get others to help out).
+
address@hidden Merges from the trunk to a branch are at the discretion of the
+branch maintainer.
+
address@hidden A merge from a branch to the trunk is treated like any other 
patch.
+In particular, it has to go through review, it must satisfy all the
+trunk requirements (build, regression test, documentation).
+
address@hidden There may be additional timing requirements on merging a branch 
to
+the trunk depending on the release schedule, etc.  For instance we may
+not want to do a branch merge just before a release.
+
address@hidden itemize
+
+If any of these rules are unclear please discuss on the list first.
+
address@hidden
 * Writing ChangeLogs::          
 @end menu
 
address@hidden Writing ChangeLogs,  , Hacking Code, Hacking Code
address@hidden Writing ChangeLogs,  , Branches, Hacking Code
 @comment node-name, next, previous, up
 @section Documenting what changed when with ChangeLog entries

signature.asc
Description: This is a digitally signed message part