Hi, This adds the branch rules we discussed on the main list to the Hacking Guide.
2005-12-11 Mark Wielaard <[EMAIL PROTECTED]>
* 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::
[EMAIL PROTECTED] menu
+
[EMAIL PROTECTED] Branches, Writing ChangeLogs, Hacking Code, Hacking Code
[EMAIL PROTECTED] node-name, next, previous, up
[EMAIL PROTECTED] 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:
+
[EMAIL PROTECTED]
+
[EMAIL PROTECTED] All branches ought to be documented in the developer wiki at
[EMAIL PROTECTED]://developer.classpath.org/mediation/ClasspathBranches}, so
+we can know which are live, who owns them, and when they die.
+
[EMAIL PROTECTED] 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.)
+
[EMAIL PROTECTED] Requirements for patch email to classpath-patches and for paperwork
[EMAIL PROTECTED] be lifted. See @ref{Requirements}.
+
[EMAIL PROTECTED] 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).
+
[EMAIL PROTECTED] Merges from the trunk to a branch are at the discretion of the
+branch maintainer.
+
[EMAIL PROTECTED] 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).
+
[EMAIL PROTECTED] 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.
+
[EMAIL PROTECTED] itemize
+
+If any of these rules are unclear please discuss on the list first.
+
[EMAIL PROTECTED]
* Writing ChangeLogs::
@end menu
[EMAIL PROTECTED] Writing ChangeLogs, , Hacking Code, Hacking Code
[EMAIL PROTECTED] 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
_______________________________________________ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
