+ *ability* to do binutils checkins, you're in this group. Just
+ remember to get approval before checking anything in.]
+
+ ------------- Obvious Fixes -------------
+
+Fixes for obvious mistakes do not need approval, and can be checked in
+right away, but the patch should still be sent to the binutils list.
+The definition of obvious is a bit hazy, and if you are not sure, then
+you should seek approval first. Obvious fixes include fixes for
+spelling mistakes, blatantly incorrect code (where the correct code is
+also blatantly obvious), and so on. Obvious fixes should always be
+small, the larger they are, the more likely it is that they contain
+some un-obvious side effect or consequence.
+
+ --------- Branch Checkins ---------
+
+If a patch is approved for check in to the mainline sources, it can
+also be checked into the current release branch. Normally however
+only bug fixes should be applied to the branch. New features, new
+ports, etc, should be restricted to the mainline. (Otherwise the
+burden of maintaining the branch in sync with the mainline becomes too
+great). If you are uncertain as to whether a patch is appropriate for
+the branch, ask the branch maintainer. This is:
+
+ Daniel Jacobowitz <dan@debian.org>
+
+ -------- Testsuites ---------------
+
+In general patches to any of the binutils testsuites should be
+considered generic and sent to the binutils mailing list for
+approval. Patches to target specific tests are the responsibility the
+relevent port maintainer(s), and can be approved/checked in by them.
+Other testsuite patches need the approval of a blanket-write-priveleges
+person.
+
+ -------- Configure patches ----------
+
+Patches to the top level configure files (config.sub & config.guess)
+are not the domain of the binutils project and they cannot be approved
+by the binutils group. Instead they should be submitted to the config
+maintainer at:
+
+ config-patches@gnu.org
+
+ --------- Creating Branches ---------
+
+Anyone with at least write-after-approval access may create a branch
+to use for their own development purposes. In keeping with FSF
+policies, all patches applied to such a branch must come from people
+with appropriate copyright assignments on file. All legal
+requirements that would apply to any other contribution apply equally
+to contributions on a branch.
+
+Before creating the branch, you should select a name for the branch of
+the form:
+
+ binutils-<org>-<name>
+
+where "org" is the initials of your organization, or your own initials
+if you are acting as an individual. For example, for a branch created
+by The GNUDist Company, "tgc" would be an appropriate choice for
+"org". It's up to each organization to select an appropriate choice
+for "name"; some organizations may use more structure than others, so
+"name" may contain additional hyphens.
+
+Suppose that The GNUDist Company was creating a branch to develop a
+port of Binutils to the FullMonty processor. Then, an appropriate
+choice of branch name would be:
+
+ binutils-tgc-fm
+
+A data stamp is not required as part of the name field, but some
+organizations like to have one. If you do include the date, you
+should follow these rules:
+
+1. The date should be the date that the branch was created.
+
+2. The date should be numerical and in the form YYYYMMDD.
+
+For example:
+
+ binutils-tgc-fm_20050101
+
+would be appropriate if the branch was created on January 1st, 2005.
+
+Having selected the branch name, create the branch as follows:
+
+1. Check out binutils, so that you have a CVS checkout corresponding
+ to the initial state of your branch.
+
+2. Create a tag:
+
+ cvs tag binutils-<org>-<name>-branchpoint
+
+ That tag will allow you, and others, to easily determine what's
+ changed on the branch relative to the initial state.
+
+3. Create the branch:
+
+ cvs rtag -b -r binutils-<org>-<name>-branchpoint \
+ binutils-<org>-<name>-branch
+
+4. Document the branch:
+
+ Add a description of the branch to binutils/BRANCHES, and check
+ that file in. All branch descriptions should be added to the
+ HEAD revision of the file; it doesn't help to modify
+ binutils/BRANCHES on a branch!
+
+Please do not commit any patches to a branch you did not create
+without the explicit permission of the person who created the branch.