* Makefile.am: Run "make dep-am".

[binutils.git] / binutils / MAINTAINERS

diff --git a/binutils/MAINTAINERS b/binutils/MAINTAINERS
index b7648b87d00d41600fb8d9a9840ec3fe89284151..00f7b4580f4bbe9467db94f6bb318b94eb10fbf2 100644 (file)
--- a/binutils/MAINTAINERS
+++ b/binutils/MAINTAINERS
@@ -14,14 +14,18 @@ The home page for binutils is:
 
 and patches should be sent to:
 
-  [email protected]
+  [email protected]    or    [email protected]
   
 with "[Patch]" as part of the subject line.  Note - patches to the
-top level configure.in and config.sub scripts should be sent to:
+top level config.guess and config.sub scripts should be sent to:
 
   [email protected]
 
-and not to the binutils list.
+and not to the binutils lists.  Patches to the other top level
+configure files (configure, configure.in, config-ml.in) should
+be sent to the binutils lists, and copied to the gcc and gdb
+lists as well ([email protected] and
[email protected]).
 
                --------- Blanket Write Privs ---------
 
@@ -30,12 +34,13 @@ repository without obtaining approval first:
                
   Nick Clifton <[email protected]> (head maintainer)
   Richard Henderson <[email protected]>
-  Ian Taylor <[email protected]>
+  Ian Lance Taylor <[email protected]>
   Jeff Law <[email protected]>
-  Jim Wilson <wilson@tuliptree.org>
+  Jim Wilson <wilson@specifixinc.com>
   DJ Delorie <[email protected]>
   Alan Modra <[email protected]>
-  Michael Meissner <[email protected]>
+  Michael Meissner <[email protected]>
+  Daniel Jacobowitz <[email protected]>
 
       --------- Maintainers ---------
 
@@ -53,31 +58,42 @@ responsibility among the other maintainers.
   ALPHA            Richard Henderson <[email protected]>
   ARM             Nick Clifton <[email protected]>
   ARM             Richard Earnshaw <[email protected]>
+  ARM (Symbian)           Paul Brook <[email protected]>
+  ARM (Symbian)           Mark Mitchell <[email protected]>
   AVR             Denis Chertykov <[email protected]>
   AVR             Marek Michalkiewicz <[email protected]>
-  CONFIGURE       Ben Elliston <[email protected]>
+  BFIN            Jie Zhang <[email protected]>
+  BFIN            Bernd Schmidt <[email protected]>
+  BUILD SYSTEM    Ben Elliston <[email protected]>
+  BUILD SYSTEM    Daniel Jacobowitz <[email protected]>
   CRIS            Hans-Peter Nilsson <[email protected]>
+  CRX             Tomer Levi <[email protected]>
   DWARF2          Jason Merrill <[email protected]>
   FR30            Dave Brolley <[email protected]>
   FRV             Dave Brolley <[email protected]>
+  FRV             Alexandre Oliva <[email protected]>
+  H8300                   Anil Paranjpe <[email protected]> 
+  HPPA            Dave Anglin <[email protected]>
   HPPA elf32      Alan Modra <[email protected]>
   HPPA elf64      Jeff Law <[email protected]> [Basic maintainance only]
-  HPPA            Dave Anglin <[email protected]>
-  IA-64                   Jim Wilson <[email protected]>
+  IA-64                   Jim Wilson <[email protected]>
   IQ2000          Stan Cox <[email protected]>
   i860            Jason Eckhardt <[email protected]>
   ix86            Alan Modra <[email protected]>
   ix86 PE         Christopher Faylor <[email protected]>
   ix86 COFF       DJ Delorie <[email protected]>
   ix86            H.J.Lu <[email protected]>
-  ix86 INTEL MODE  Diego Novillo <dnovillo@redhat.com>
+  ix86 INTEL MODE  Jan Beulich <jbeulich@novell.com>
   M68HC11 M68HC12  Stephane Carrez <[email protected]>
-  M68k            Ben Elliston <[email protected]>
-  M88k            Ben Elliston <[email protected]>
-  MIPS            Eric Christopher <[email protected]>
+  M68k            Ben Elliston <[email protected]>
+  M88k            Mark Kettenis <[email protected]>
+  MAXQ            Inderpreet Singh <[email protected]>
+  MIPS            Eric Christopher <[email protected]>
+  MIPS            Thiemo Seufer <[email protected]>
   MMIX            Hans-Peter Nilsson <[email protected]>
-  MN10300         Eric Christopher <echristo@redhat.com>
+  MN10300         Eric Christopher <echristo@apple.com>
   MN10300         Alexandre Oliva <[email protected]>
+  MSP430          Dmitry Diky <[email protected]>
   PPC             Geoff Keating <[email protected]>
   PPC vector ext   Aldy Hernandez <[email protected]>
   s390, s390x     Martin Schwidefsky <[email protected]>
@@ -85,13 +101,16 @@ responsibility among the other maintainers.
   SH              Alexandre Oliva <[email protected]>
   SH              Kaz Kojima <[email protected]>
   SPARC                   Jakub Jelinek <[email protected]>
-  TESTSUITES      Ben Elliston <bje@wasabisystems.com>
-  TIC4X            Svein Seldal <svein.seldal@solidas.com>
+  TESTSUITES      Ben Elliston <bje@gnu.org>
+  TIC4X            Svein Seldal <svein@dev.seldal.com>
   TIC54X           Timothy Wall <[email protected]>
-  VAX             Jason R Thorpe <[email protected]>
+  VAX             Jason R Thorpe <[email protected]>
+  VAX             Jan-Benedict Glaw <[email protected]>
   x86_64          Jan Hubicka <[email protected]>
   x86_64          Andreas Jaeger <[email protected]>
+  x86_64          H.J.Lu <[email protected]>
   Xtensa          Bob Wilson <[email protected]>
+  z80             Arnold Metselaar <[email protected]>
   z8k             Christian Groessler <[email protected]>
 
 
@@ -161,3 +180,71 @@ by the binutils group.  Instead they should be submitted to the config
 maintainer at:
 
        [email protected]
+
+    --------- 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.