head	1.2;
access;
symbols
	RELENG_8_4:1.2.0.8
	RELENG_9_1_0_RELEASE:1.2
	RELENG_9_1:1.2.0.6
	RELENG_9_1_BP:1.2
	RELENG_8_3_0_RELEASE:1.1.1.7
	RELENG_8_3:1.1.1.7.0.42
	RELENG_8_3_BP:1.1.1.7
	RELENG_9_0_0_RELEASE:1.2
	RELENG_9_0:1.2.0.4
	RELENG_9_0_BP:1.2
	RELENG_9:1.2.0.2
	RELENG_9_BP:1.2
	RELENG_7_4_0_RELEASE:1.1.1.7
	RELENG_8_2_0_RELEASE:1.1.1.7
	RELENG_7_4:1.1.1.7.0.40
	RELENG_7_4_BP:1.1.1.7
	RELENG_8_2:1.1.1.7.0.38
	RELENG_8_2_BP:1.1.1.7
	RELENG_8_1_0_RELEASE:1.1.1.7
	RELENG_8_1:1.1.1.7.0.36
	RELENG_8_1_BP:1.1.1.7
	RELENG_7_3_0_RELEASE:1.1.1.7
	RELENG_7_3:1.1.1.7.0.34
	RELENG_7_3_BP:1.1.1.7
	RELENG_8_0_0_RELEASE:1.1.1.7
	RELENG_8_0:1.1.1.7.0.32
	RELENG_8_0_BP:1.1.1.7
	RELENG_8:1.1.1.7.0.30
	RELENG_8_BP:1.1.1.7
	RELENG_7_2_0_RELEASE:1.1.1.7
	RELENG_7_2:1.1.1.7.0.28
	RELENG_7_2_BP:1.1.1.7
	RELENG_7_1_0_RELEASE:1.1.1.7
	RELENG_6_4_0_RELEASE:1.1.1.7
	RELENG_7_1:1.1.1.7.0.26
	RELENG_7_1_BP:1.1.1.7
	RELENG_6_4:1.1.1.7.0.24
	RELENG_6_4_BP:1.1.1.7
	RELENG_7_0_0_RELEASE:1.1.1.7
	RELENG_6_3_0_RELEASE:1.1.1.7
	RELENG_7_0:1.1.1.7.0.22
	RELENG_7_0_BP:1.1.1.7
	RELENG_6_3:1.1.1.7.0.20
	RELENG_6_3_BP:1.1.1.7
	RELENG_7:1.1.1.7.0.18
	RELENG_7_BP:1.1.1.7
	RELENG_6_2_0_RELEASE:1.1.1.7
	RELENG_6_2:1.1.1.7.0.16
	RELENG_6_2_BP:1.1.1.7
	RELENG_5_5_0_RELEASE:1.1.1.7
	RELENG_5_5:1.1.1.7.0.14
	RELENG_5_5_BP:1.1.1.7
	RELENG_6_1_0_RELEASE:1.1.1.7
	RELENG_6_1:1.1.1.7.0.12
	RELENG_6_1_BP:1.1.1.7
	RELENG_6_0_0_RELEASE:1.1.1.7
	RELENG_6_0:1.1.1.7.0.10
	RELENG_6_0_BP:1.1.1.7
	RELENG_6:1.1.1.7.0.8
	RELENG_6_BP:1.1.1.7
	RELENG_5_4_0_RELEASE:1.1.1.7
	RELENG_5_4:1.1.1.7.0.6
	RELENG_5_4_BP:1.1.1.7
	RELENG_4_11_0_RELEASE:1.1.1.2.2.2
	RELENG_4_11:1.1.1.2.2.2.0.10
	RELENG_4_11_BP:1.1.1.2.2.2
	RELENG_5_3_0_RELEASE:1.1.1.7
	RELENG_5_3:1.1.1.7.0.4
	RELENG_5_3_BP:1.1.1.7
	RELENG_5:1.1.1.7.0.2
	RELENG_5_BP:1.1.1.7
	binutils_2_15_20040523:1.1.1.7
	RELENG_4_10_0_RELEASE:1.1.1.2.2.2
	RELENG_4_10:1.1.1.2.2.2.0.8
	RELENG_4_10_BP:1.1.1.2.2.2
	RELENG_5_2_1_RELEASE:1.1.1.6
	RELENG_5_2_0_RELEASE:1.1.1.6
	RELENG_5_2:1.1.1.6.0.6
	RELENG_5_2_BP:1.1.1.6
	RELENG_4_9_0_RELEASE:1.1.1.2.2.2
	RELENG_4_9:1.1.1.2.2.2.0.6
	RELENG_4_9_BP:1.1.1.2.2.2
	RELENG_5_1_0_RELEASE:1.1.1.6
	RELENG_5_1:1.1.1.6.0.4
	RELENG_5_1_BP:1.1.1.6
	RELENG_4_8_0_RELEASE:1.1.1.2.2.2
	RELENG_4_8:1.1.1.2.2.2.0.4
	RELENG_4_8_BP:1.1.1.2.2.2
	RELENG_5_0_0_RELEASE:1.1.1.6
	RELENG_5_0:1.1.1.6.0.2
	RELENG_5_0_BP:1.1.1.6
	binutils_2_13_2_20021127:1.1.1.6
	binutils_2_13_20021011:1.1.1.6
	RELENG_4_7_0_RELEASE:1.1.1.2.2.2
	RELENG_4_7:1.1.1.2.2.2.0.2
	RELENG_4_7_BP:1.1.1.2.2.2
	BEFORE_BU_2121__RELENG4:1.1.1.2.2.1
	binutils_2_12_20020720:1.1.1.5
	RELENG_4_6_2_RELEASE:1.1.1.2.2.1
	RELENG_4_6_1_RELEASE:1.1.1.2.2.1
	binutils_2_12_20020622:1.1.1.5
	RELENG_4_6_0_RELEASE:1.1.1.2.2.1
	RELENG_4_6:1.1.1.2.2.1.0.6
	RELENG_4_6_BP:1.1.1.2.2.1
	binutils_2_12_20020410:1.1.1.4
	BEFORE_BU_2_12:1.1.1.2
	binutils_2_12_anoncvs_20020320:1.1.1.4
	binutils_2_12_anoncvs_20020221:1.1.1.4
	RELENG_4_5_0_RELEASE:1.1.1.2.2.1
	binutils_anoncvs_20020127:1.1.1.3
	RELENG_4_5:1.1.1.2.2.1.0.4
	RELENG_4_5_BP:1.1.1.2.2.1
	binutils_2_11_cvs_20011031:1.1.1.2
	RELENG_4_4_0_RELEASE:1.1.1.2.2.1
	RELENG_4_4:1.1.1.2.2.1.0.2
	RELENG_4_4_BP:1.1.1.2.2.1
	RELENG_4:1.1.1.2.0.2
	binutils_2_11_cvs_20010719:1.1.1.2
	binutils_2_11_2:1.1.1.2
	binutils_2_11_0:1.1.1.1
	FSF:1.1.1;
locks; strict;
comment	@# @;


1.2
date	2011.02.18.20.54.12;	author dim;	state Exp;
branches
	1.2.8.1;
next	1.1;

1.1
date	2001.05.28.05.19.50;	author obrien;	state Exp;
branches
	1.1.1.1;
next	;

1.2.8.1
date	2011.02.18.20.54.12;	author svnexp;	state dead;
branches;
next	1.2.8.2;

1.2.8.2
date	2013.03.28.13.00.30;	author svnexp;	state Exp;
branches;
next	;

1.1.1.1
date	2001.05.28.05.19.50;	author obrien;	state Exp;
branches;
next	1.1.1.2;

1.1.1.2
date	2001.06.26.16.55.52;	author obrien;	state Exp;
branches
	1.1.1.2.2.1;
next	1.1.1.3;

1.1.1.3
date	2002.01.27.11.58.23;	author obrien;	state Exp;
branches;
next	1.1.1.4;

1.1.1.4
date	2002.02.22.04.16.52;	author obrien;	state Exp;
branches;
next	1.1.1.5;

1.1.1.5
date	2002.07.05.20.14.41;	author obrien;	state Exp;
branches;
next	1.1.1.6;

1.1.1.6
date	2002.10.11.05.59.32;	author obrien;	state Exp;
branches;
next	1.1.1.7;

1.1.1.7
date	2004.06.16.05.44.04;	author obrien;	state Exp;
branches;
next	;

1.1.1.2.2.1
date	2001.08.01.23.02.40;	author obrien;	state Exp;
branches;
next	1.1.1.2.2.2;

1.1.1.2.2.2
date	2002.09.01.23.43.46;	author obrien;	state Exp;
branches;
next	;


desc
@@


1.2
log
@SVN rev 218822 on 2011-02-18 20:54:12Z by dim

Merge binutils 2.17.50 to head.  This brings a number of improvements to
x86 CPU support, better support for powerpc64, some new directives, and
many other things.  Bump __FreeBSD_version, and add a note to UPDATING.

Thanks to the many people that have helped to test this.

Obtained from:	projects/binutils-2.17
@
text
@		========= Binutils Maintainers =========

This is the list of individuals responsible for maintenance and update
of the GNU Binary Utilities project.  This includes the linker (ld),
the assembler (gas), the profiler (gprof), a whole suite of other
programs (binutils) and the libraries that they use (bfd and
opcodes).  This project shares a common set of header files with the
GCC and GDB projects (include), so maintainership of those files is
shared amoungst the projects.

The home page for binutils is:

  http://www.gnu.org/software/binutils/binutils.html

and patches should be sent to:

  binutils@@sourceware.org

with "[Patch]" as part of the subject line.  Note - patches to the
top level config.guess and config.sub scripts should be sent to:

  config-patches@@gnu.org

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 (gcc-patches@@gcc.gnu.org and
gdb-patches@@sourceware.org).

		--------- Blanket Write Privs ---------

The following people have permission to check patches into the
repository without obtaining approval first:

  Nick Clifton <nickc@@redhat.com> (head maintainer)
  Richard Henderson <rth@@redhat.com>
  Ian Lance Taylor <ian@@airs.com>
  Jeff Law <law@@redhat.com>
  Jim Wilson <wilson@@specifixinc.com>
  DJ Delorie <dj@@redhat.com>
  Alan Modra <amodra@@bigpond.net.au>
  Michael Meissner <gnu@@the-meissners.org>
  Daniel Jacobowitz <dan@@debian.org>

      --------- Maintainers ---------

Maintainers are individuals who are responsible for, and have
permission to check in changes in, certain subsets of the code.  Note
that maintainers still need approval to check in changes outside of
the immediate domain that they maintain.

If there is no maintainer for a given domain then the responsibility
falls to the head maintainer (above).  If there are several
maintainers for a given domain then responsibility falls to the first
maintainer.  The first maintainer is free to devolve that
responsibility among the other maintainers.

  ALPHA            Richard Henderson <rth@@redhat.com>
  ARM		   Nick Clifton <nickc@@redhat.com>
  ARM		   Richard Earnshaw <rearnsha@@arm.com>
  ARM		   Paul Brook <paul@@codesourcery.com>
  ARM (Symbian)	   Mark Mitchell <mark@@codesourcery.com>
  AVR		   Denis Chertykov <denisc@@overta.ru>
  AVR		   Marek Michalkiewicz <marekm@@amelek.gda.pl>
  BFIN		   Jie Zhang <jie.zhang@@analog.com>
  BFIN		   Bernd Schmidt <bernd.schmidt@@analog.com>
  BUILD SYSTEM	   Ben Elliston <bje@@gnu.org>
  BUILD SYSTEM	   Daniel Jacobowitz <dan@@debian.org>
  CRIS		   Hans-Peter Nilsson <hp@@axis.com>
  CRX		   Tomer Levi <Tomer.Levi@@nsc.com>
  DLX              Nikolaos Kavvadias <nkavv@@physics.auth.gr>
  DWARF2	   Jason Merrill <jason@@redhat.com>
  FR30		   Dave Brolley <brolley@@redhat.com>
  FRV		   Dave Brolley <brolley@@redhat.com>
  FRV		   Alexandre Oliva <aoliva@@redhat.com>
  H8300		   Anil Paranjpe <anilp1@@kpitcummins.com>
  HPPA		   Dave Anglin <dave.anglin@@nrc.ca>
  HPPA elf32	   Alan Modra <amodra@@bigpond.net.au>
  HPPA elf64	   Jeff Law <law@@redhat.com> [Basic maintainance only]
  IA-64		   Jim Wilson <wilson@@specifixinc.com>
  IQ2000	   Stan Cox <scox@@redhat.com>
  i860		   Jason Eckhardt <jle@@rice.edu>
  ix86		   Alan Modra <amodra@@bigpond.net.au>
  ix86 PE	   Christopher Faylor <cgf@@redhat.com>
  ix86 COFF	   DJ Delorie <dj@@redhat.com>
  ix86		   H.J. Lu <hjl@@gnu.org>
  ix86 INTEL MODE  Jan Beulich <jbeulich@@novell.com>
  M68HC11 M68HC12  Stephane Carrez <stcarrez@@nerim.fr>
  M68k		   Ben Elliston <bje@@gnu.org>
  M88k		   Mark Kettenis <kettenis@@gnu.org>
  MAXQ		   Inderpreet Singh <inderpreetb@@noida.hcltech.com>
  MEP		   Dave Brolley <brolley@@redhat.com>
  MIPS		   Eric Christopher <echristo@@apple.com>
  MIPS		   Thiemo Seufer <ths@@networkno.de>
  MMIX		   Hans-Peter Nilsson <hp@@bitrange.com>
  MN10300	   Eric Christopher <echristo@@apple.com>
  MN10300	   Alexandre Oliva <aoliva@@redhat.com>
  MSP430	   Dmitry Diky <diwil@@spec.ru>
  NetBSD support   Matt Thomas <matt@@netbsd.org>
  PPC		   Geoff Keating <geoffk@@geoffk.org>
  PPC		   Alan Modra <amodra@@bigpond.net.au>
  PPC vector ext   Aldy Hernandez <aldyh@@redhat.com>
  s390, s390x	   Martin Schwidefsky <schwidefsky@@de.ibm.com>
  SCORE		   Mei Ligang <ligang@@sunnorth.com.cn>
  SH		   Alexandre Oliva <aoliva@@redhat.com>
  SH		   Kaz Kojima <kkojima@@rr.iij4u.or.jp>
  SPARC		   Jakub Jelinek <jakub@@redhat.com>
  TESTSUITES	   Ben Elliston <bje@@gnu.org>
  TIC4X            Svein Seldal <svein@@dev.seldal.com>
  TIC54X           Timothy Wall <twall@@alum.mit.edu>
  VAX		   Matt Thomas <matt@@netbsd.org>
  VAX		   Jan-Benedict Glaw <jbglaw@@lug-owl.de>
  x86_64	   Jan Hubicka <jh@@suse.cz>
  x86_64	   Andreas Jaeger <aj@@suse.de>
  x86_64	   H.J. Lu <hjl@@gnu.org>
  Xtensa	   Bob Wilson <bob.wilson@@acm.org>
  z80		   Arnold Metselaar <arnold.metselaar@@planet.nl>
  z8k		   Christian Groessler <chris@@groessler.org>


      --------- CGEN Maintainers -------------

CGEN is a tool for building, amongst other things, assemblers,
disassemblers and simulators from a single description of a CPU.
It creates files in several of the binutils directories, but it
is mentioned here since there is a single group that maintains
CGEN and the files that it creates.

If you have CGEN related problems you can send email to;

   cgen@@sourceware.org

The current CGEN maintainers are:

  Doug Evans, Frank Eigler

     --------- Write After Approval ---------

Individuals with "write after approval" have the ability to check in
changes, but they must get approval for each change from someone in
one of the above lists (blanket write or maintainers).

[It's a huge list, folks.  You know who you are.  If you have the
 *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.
@


1.2.8.1
log
@file MAINTAINERS was added on branch RELENG_8_4 on 2013-03-28 13:00:30 +0000
@
text
@d1 254
@


1.2.8.2
log
@## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/248810
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
@
text
@a0 168
		========= Binutils Maintainers =========

This is the list of individuals responsible for maintenance and update
of the GNU Binary Utilities project.  This includes the linker (ld),
the assembler (gas), the profiler (gprof), a whole suite of other
programs (binutils) and the libraries that they use (bfd and
opcodes).  This project shares a common set of header files with the
GCC and GDB projects (include), so maintainership of those files is 
shared amoungst the projects.

The home page for binutils is:

  http://www.gnu.org/software/binutils/binutils.html

and patches should be sent to:

  bug-binutils@@gnu.org    or    binutils@@sources.redhat.com
  
with "[Patch]" as part of the subject line.  Note - patches to the
top level config.guess and config.sub scripts should be sent to:

  config-patches@@gnu.org

and not to the binutils lists.  Patches to the other top level
configure files (configure, configure.in, config-if, config-ml.in)
should be sent to the binutils lists, and copied to the gcc and gdb
lists as well (gcc-patches@@gcc.gnu.org and
gdb-patches@@sources.redhat.com).

		--------- Blanket Write Privs ---------

The following people have permission to check patches into the
repository without obtaining approval first:
		
  Nick Clifton <nickc@@redhat.com> (head maintainer)
  Richard Henderson <rth@@redhat.com>
  Ian Taylor <ian@@wasabisystems.com>
  Jeff Law <law@@redhat.com>
  Jim Wilson <wilson@@specifixinc.com>
  DJ Delorie <dj@@redhat.com>
  Alan Modra <amodra@@bigpond.net.au>
  Michael Meissner <gnu@@the-meissners.org>

      --------- Maintainers ---------

Maintainers are individuals who are responsible for, and have
permission to check in changes in, certain subsets of the code.  Note
that maintainers still need approval to check in changes outside of
the immediate domain that they maintain.

If there is no maintainer for a given domain then the responsibility
falls to the head maintainer (above).  If there are several
maintainers for a given domain then responsibility falls to the first
maintainer.  The first maintainer is free to devolve that
responsibility among the other maintainers.

  ALPHA            Richard Henderson <rth@@redhat.com>
  ARM		   Nick Clifton <nickc@@redhat.com>
  ARM		   Richard Earnshaw <rearnsha@@arm.com>
  AVR		   Denis Chertykov <denisc@@overta.ru>
  AVR		   Marek Michalkiewicz <marekm@@amelek.gda.pl>
  BUILD SYSTEM	   Ben Elliston <bje@@gnu.org>
  BUILD SYSTEM	   Daniel Jacobowitz <dan@@debian.org>
  CRIS		   Hans-Peter Nilsson <hp@@axis.com>
  DWARF2	   Jason Merrill <jason@@redhat.com>
  FR30		   Dave Brolley <brolley@@redhat.com>
  FRV		   Dave Brolley <brolley@@redhat.com>
  HPPA		   Dave Anglin <dave.anglin@@nrc.ca>
  HPPA elf32	   Alan Modra <amodra@@bigpond.net.au>
  HPPA elf64	   Jeff Law <law@@redhat.com> [Basic maintainance only]
  IA-64		   Jim Wilson <wilson@@specifixinc.com>
  IQ2000	   Stan Cox <scox@@redhat.com>
  i860		   Jason Eckhardt <jle@@rice.edu>
  ix86		   Alan Modra <amodra@@bigpond.net.au>
  ix86 PE	   Christopher Faylor <cgf@@redhat.com>
  ix86 COFF	   DJ Delorie <dj@@redhat.com>
  ix86		   H.J.Lu <hjl@@gnu.org>
  ix86 INTEL MODE  Diego Novillo <dnovillo@@redhat.com>
  M68HC11 M68HC12  Stephane Carrez <stcarrez@@nerim.fr>
  M68k		   Ben Elliston <bje@@gnu.org>
  MIPS		   Eric Christopher <echristo@@redhat.com>
  MIPS		   Thiemo Seufer <seufer@@csv.ica.uni-stuttgart.de>
  MMIX		   Hans-Peter Nilsson <hp@@bitrange.com>
  MN10300	   Eric Christopher <echristo@@redhat.com>
  MN10300	   Alexandre Oliva <aoliva@@redhat.com>
  PPC		   Geoff Keating <geoffk@@geoffk.org>
  PPC vector ext   Aldy Hernandez <aldyh@@redhat.com>
  s390, s390x	   Martin Schwidefsky <schwidefsky@@de.ibm.com>
  SH		   Jrn Rennecke <joern.rennecke@@superh.com>
  SH		   Alexandre Oliva <aoliva@@redhat.com>
  SH		   Kaz Kojima <kkojima@@rr.iij4u.or.jp>
  SPARC		   Jakub Jelinek <jakub@@redhat.com>
  TESTSUITES	   Ben Elliston <bje@@gnu.org>
  TIC4X            Svein Seldal <svein.seldal@@solidas.com>
  TIC54X           Timothy Wall <twall@@alum.mit.edu>
  VAX		   Jason R Thorpe <thorpej@@wasabisystems.com>
  x86_64	   Jan Hubicka <jh@@suse.cz>
  x86_64	   Andreas Jaeger <aj@@suse.de>
  Xtensa	   Bob Wilson <bob.wilson@@acm.org>
  z8k		   Christian Groessler <chris@@groessler.org>


      --------- CGEN Maintainers -------------

CGEN is a tool for building, amongst other things, assemblers,
disassemblers and simulators from a single description of a CPU.
It creates files in several of the binutils directories, but it
is mentioned here since there is a single group that maintains
CGEN and the files that it creates. 

If you have CGEN related problems you can send email to;

   cgen@@sources.redhat.com

The current CGEN maintainers are:

  Doug Evans, Ben Elliston, Frank Eigler

     --------- Write After Approval ---------

Individuals with "write after approval" have the ability to check in
changes, but they must get approval for each change from someone in
one of the above lists (blanket write or maintainers).

[It's a huge list, folks.  You know who you are.  If you have the
 *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
@


1.1
log
@Initial revision
@
text
@d4 25
a28 4
of the "binutils" module, which includes the bfd, binutils, include,
gas, gprof, ld, and opcodes subdirectories.  The home page for binutils
is http://sources.redhat.com/binutils/ and patches should be sent to
binutils@@sources.redhat.com with "[patch]" as part of the subject.
d32 19
a50 15
Nick Clifton <nickc@@redhat.com> (head maintainer)
Richard Henderson <rth@@redhat.com>
Ian Taylor <ian@@zembu.com>
Jeff Law <law@@redhat.com>
Jim Wilson <wilson@@redhat.com>
DJ Delorie <dj@@redhat.com>
Alan Modra <alan@@linuxcare.com.au>
Michael Meissner <meissner@@redhat.com>

		    --------- Maintainers ---------

Maintainers are individuals who are responsible for, and have permission
to check in changes in, certain subsets of the code.  Note that
maintainers still need approval to check in changes outside of the
immediate domain that they maintain.
d53 67
a119 25
falls to the head maintainer (above).  If there are several maintainers
for a given domain then responsibility falls to the first maintainer.
The first maintainer is free to devolve that responsibility among the
other maintainers.

ARM		Nick Clifton <nickc@@redhat.com>
AVR		Denis Chertykov <denisc@@overta.ru>
CRIS		Hans-Peter Nilsson <hp@@axis.com>
HPPA elf32	Alan Modra <alan@@linuxcare.com.au>
IA64		Jim Wilson <wilson@@redhat.com>
i860		Jason Eckhardt <jle@@redhat.com>
ix86		Alan Modra <alan@@linuxcare.com.au>
ix86 COFF,PE	DJ Delorie <dj@@redhat.com>
ix86		H.J.Lu <hjl@@gnu.org>
ix86 INTEL MODE Diego Novillo <dnovillo@@redhat.com>
MN10300		Eric Christopher <echristo@@redhat.com>
MIPS		Ulf Carlsson <ulfc@@calypso.engr.sgi.com>
PPC		Geoff Keating <geoffk@@redhat.com>
SH		Jrn Rennecke <amylaar@@redhat.com>
SH		Hans-Peter Nilsson <hp@@bitrange.com>
SPARC		Jakub Jelinek <jakub@@redhat.com>
68HC11 68HC12   Stephane Carrez <Stephane.Carrez@@worldnet.fr>
DWARF2		Jason Merrill <jason@@redhat.com>
x86_64		Jan Hubicka <jh@@suse.cz>
x86_64		Andreas Jaeger <aj@@suse.de>
d121 1
a121 1
               --------- CGEN Maintainers -------------
d124 4
a127 4
disassemblers and simulators from a single description of a CPU.  It
creates files in several of the binutils directories, but it is
mentioned here since there is a single group that maintains CGEN and
the files that it creates. 
d131 1
a131 1
             cgen@@sources.redhat.com
d135 1
a135 1
  Doug Evans, Ben Elliston, Frank Eigler
d137 1
a137 1
	       --------- Write After Approval ---------
d144 111
a254 2
 *ability* to do binutils checkins, you're in this group.  Just remember
 to get approval before checking anything in.]
@


1.1.1.1
log
@Import of GNU Binutils version 2.11.0.
Believe it or not, this is heavily stripped down.
@
text
@@


1.1.1.2
log
@Import of GNU Binutils version 2.11.2.
@
text
@a8 3
Note - patches to the top level configure.in and config.sub scripts
should be sent to config-patches@@gnu.org and not to the binutils list.

d17 1
a17 1
Alan Modra <amodra@@bigpond.net.au>
d36 1
a36 1
HPPA elf32	Alan Modra <amodra@@bigpond.net.au>
d39 1
a39 1
ix86		Alan Modra <amodra@@bigpond.net.au>
a78 11

	       -------------  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.
@


1.1.1.3
log
@Enlist the FreeBSD-CURRENT users as testers of what is to become Binutils
version 2.12.0.  These bits are taken from the FSF anoncvs repo on
27-January-2002 03:41 PST.
@
text
@d4 4
a7 6
of the GNU Binary Utilities project.  This includes the linker (ld),
the assembler (gas), the profiler (gprof), a whole suite of other
programs (binutils) and the libraries that they use (bfd and
opcodes).  This project shares a common set of header files with the
GCC and GDB projects (include), so maintainership of those files is 
shared amoungst the projects.
d9 2
a10 14
The home page for binutils is:

  http://www.gnu.org/software/binutils/binutils.html

and patches should be sent to:

  bug-binutils@@gnu.org
  
with "[Patch]" as part of the subject line.  Note - patches to the
top level configure.in and config.sub scripts should be sent to:

  config-patches@@gnu.org

and not to the binutils list.
d14 15
a28 18
The following people have permission to check patches into the
repository without obtaining approval first:
		
  Nick Clifton <nickc@@redhat.com> (head maintainer)
  Richard Henderson <rth@@redhat.com>
  Ian Taylor <ian@@zembu.com>
  Jeff Law <law@@redhat.com>
  Jim Wilson <wilson@@redhat.com>
  DJ Delorie <dj@@redhat.com>
  Alan Modra <amodra@@bigpond.net.au>
  Michael Meissner <meissner@@redhat.com>

      --------- Maintainers ---------

Maintainers are individuals who are responsible for, and have
permission to check in changes in, certain subsets of the code.  Note
that maintainers still need approval to check in changes outside of
the immediate domain that they maintain.
d31 25
a55 33
falls to the head maintainer (above).  If there are several
maintainers for a given domain then responsibility falls to the first
maintainer.  The first maintainer is free to devolve that
responsibility among the other maintainers.

  ARC		   Peter Targett <peter.targett@@arccores.com>
  ARM		   Nick Clifton <nickc@@redhat.com>
  ARM		   Richard Earnshaw <rearnsha@@arm.com>
  AVR		   Denis Chertykov <denisc@@overta.ru>
  CRIS		   Hans-Peter Nilsson <hp@@axis.com>
  DWARF2	   Jason Merrill <jason@@redhat.com>
  HPPA elf32	   Alan Modra <amodra@@bigpond.net.au>
  IA64		   Jim Wilson <wilson@@redhat.com>
  x86_64	   Jan Hubicka <jh@@suse.cz>
  x86_64	   Andreas Jaeger <aj@@suse.de>
  i860		   Jason Eckhardt <jle@@redhat.com>
  ix86		   Alan Modra <amodra@@bigpond.net.au>
  ix86 COFF,PE	   DJ Delorie <dj@@redhat.com>
  ix86		   H.J.Lu <hjl@@gnu.org>
  ix86 INTEL MODE  Diego Novillo <dnovillo@@redhat.com>
  M68HC11 M68HC12  Stephane Carrez <Stephane.Carrez@@worldnet.fr>
  MN10300	   Eric Christopher <echristo@@redhat.com>
  MIPS		   Eric Christopher <echristo@@redhat.com>
  M88k		   Ben Elliston <bje@@redhat.com>
  MMIX		   Hans-Peter Nilsson <hp@@bitrange.com>
  PPC		   Geoff Keating <geoffk@@redhat.com>
  PPC XCOFF	   Tom Rix <trix@@redhat.com>
  s390, s390x	   Martin Schwidefsky <schwidefsky@@de.ibm.com>
  SH		   Jrn Rennecke <amylaar@@onetel.net.uk>
  SH		   Hans-Peter Nilsson <hp@@bitrange.com>
  SPARC		   Jakub Jelinek <jakub@@redhat.com>
  TIC54X           Timothy Wall <twall@@alum.mit.edu>
  z8k		   Christian Groessler <cpg@@aladdin.de>
d57 1
a57 1
      --------- CGEN Maintainers -------------
d60 4
a63 4
disassemblers and simulators from a single description of a CPU.
It creates files in several of the binutils directories, but it
is mentioned here since there is a single group that maintains
CGEN and the files that it creates. 
d67 1
a67 1
   cgen@@sources.redhat.com
d73 1
a73 1
     --------- Write After Approval ---------
d80 2
a81 2
 *ability* to do binutils checkins, you're in this group.  Just
 remember to get approval before checking anything in.]
d83 1
a83 1
     -------------  Obvious Fixes -------------
a92 12

    --------- 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:

   Philip Blundell  <philb@@gnu.org>
@


1.1.1.4
log
@Import of Binutils from the FSF 2.12 branch (pre-.0 release).

These bits are taken from the FSF anoncvs repo on 21-Feburary-2002 20:15 PST.
@
text
@a69 1
  MN10300	   Alexandre Oliva <aoliva@@redhat.com>
a77 1
  SH		   Alexandre Oliva <aoliva@@redhat.com>
d129 1
a129 1
   Daniel Jacobowitz  <dan@@debian.org>
@


1.1.1.5
log
@Import of Binutils from the FSF 2.12 branch (just post-.1 release).
These bits are taken from the FSF anoncvs repo on 22-June-2002 23:28:00 EDT.
@
text
@d53 1
a53 1
  ARC		   Peter Targett <peter.targett@@arc.com>
d77 1
a77 1
  SH		   Jrn Rennecke <joern.rennecke@@superh.com>
d82 1
a82 2
  z8k		   Christian Groessler <chris@@groessler.org>

@


1.1.1.6
log
@Import of Binutils from the FSF 2.13 branch (just pre-.1 release).
These bits are taken from the FSF anoncvs repo on 11-Oct-2002 22:39:35 PDT.
@
text
@a56 1
  AVR		   Marek Michalkiewicz <marekm@@amelek.gda.pl>
a58 2
  FR30		   Dave Brolley <brolley@@redhat.com>
  FRV		   Dave Brolley <brolley@@redhat.com>
d61 2
d68 4
a71 2
  M68HC11 M68HC12  Stephane Carrez <stcarrez@@nerim.fr>
  M68k		   Ben Elliston <bje@@redhat.com>
a72 1
  MIPS		   Eric Christopher <echristo@@redhat.com>
a73 2
  MN10300	   Eric Christopher <echristo@@redhat.com>
  MN10300	   Alexandre Oliva <aoliva@@redhat.com>
d75 1
d77 1
a77 1
  SH		   Jrn Rennecke <joern.rennecke@@superh.com>
a81 3
  VAX		   Jason R Thorpe <thorpej@@wasabisystems.com>
  x86_64	   Jan Hubicka <jh@@suse.cz>
  x86_64	   Andreas Jaeger <aj@@suse.de>
@


1.1.1.7
log
@Import of Binutils from the FSF 2.15 branch (just post-.0 release).
These bits are taken from the FSF anoncvs repo on 23-May-2004 04:41:00 UTC.
@
text
@d17 1
a17 1
  bug-binutils@@gnu.org    or    binutils@@sources.redhat.com
d20 1
a20 1
top level config.guess and config.sub scripts should be sent to:
d24 1
a24 5
and not to the binutils lists.  Patches to the other top level
configure files (configure, configure.in, config-if, config-ml.in)
should be sent to the binutils lists, and copied to the gcc and gdb
lists as well (gcc-patches@@gcc.gnu.org and
gdb-patches@@sources.redhat.com).
d33 1
a33 1
  Ian Taylor <ian@@wasabisystems.com>
d35 1
a35 1
  Jim Wilson <wilson@@specifixinc.com>
d38 1
a38 1
  Michael Meissner <gnu@@the-meissners.org>
d53 1
a53 1
  ALPHA            Richard Henderson <rth@@redhat.com>
a57 2
  BUILD SYSTEM	   Ben Elliston <bje@@gnu.org>
  BUILD SYSTEM	   Daniel Jacobowitz <dan@@debian.org>
a61 1
  HPPA		   Dave Anglin <dave.anglin@@nrc.ca>
d63 2
a64 4
  HPPA elf64	   Jeff Law <law@@redhat.com> [Basic maintainance only]
  IA-64		   Jim Wilson <wilson@@specifixinc.com>
  IQ2000	   Stan Cox <scox@@redhat.com>
  i860		   Jason Eckhardt <jle@@rice.edu>
d66 1
a66 2
  ix86 PE	   Christopher Faylor <cgf@@redhat.com>
  ix86 COFF	   DJ Delorie <dj@@redhat.com>
d70 2
a71 1
  M68k		   Ben Elliston <bje@@gnu.org>
a72 1
  MIPS		   Thiemo Seufer <seufer@@csv.ica.uni-stuttgart.de>
d76 1
a76 2
  PPC		   Geoff Keating <geoffk@@geoffk.org>
  PPC vector ext   Aldy Hernandez <aldyh@@redhat.com>
d79 1
a80 1
  SH		   Kaz Kojima <kkojima@@rr.iij4u.or.jp>
a81 2
  TESTSUITES	   Ben Elliston <bje@@gnu.org>
  TIC4X            Svein Seldal <svein.seldal@@solidas.com>
a85 1
  Xtensa	   Bob Wilson <bob.wilson@@acm.org>
a136 18

    -------- 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
@


1.1.1.2.2.1
log
@MFC: update to Binutils 2.11.2.
@
text
@@


1.1.1.2.2.2
log
@Upgrade to binutils 2.12.1.
@
text
@d4 4
a7 6
of the GNU Binary Utilities project.  This includes the linker (ld),
the assembler (gas), the profiler (gprof), a whole suite of other
programs (binutils) and the libraries that they use (bfd and
opcodes).  This project shares a common set of header files with the
GCC and GDB projects (include), so maintainership of those files is 
shared amoungst the projects.
d9 2
a10 14
The home page for binutils is:

  http://www.gnu.org/software/binutils/binutils.html

and patches should be sent to:

  bug-binutils@@gnu.org
  
with "[Patch]" as part of the subject line.  Note - patches to the
top level configure.in and config.sub scripts should be sent to:

  config-patches@@gnu.org

and not to the binutils list.
d14 15
a28 18
The following people have permission to check patches into the
repository without obtaining approval first:
		
  Nick Clifton <nickc@@redhat.com> (head maintainer)
  Richard Henderson <rth@@redhat.com>
  Ian Taylor <ian@@zembu.com>
  Jeff Law <law@@redhat.com>
  Jim Wilson <wilson@@redhat.com>
  DJ Delorie <dj@@redhat.com>
  Alan Modra <amodra@@bigpond.net.au>
  Michael Meissner <meissner@@redhat.com>

      --------- Maintainers ---------

Maintainers are individuals who are responsible for, and have
permission to check in changes in, certain subsets of the code.  Note
that maintainers still need approval to check in changes outside of
the immediate domain that they maintain.
d31 25
a55 35
falls to the head maintainer (above).  If there are several
maintainers for a given domain then responsibility falls to the first
maintainer.  The first maintainer is free to devolve that
responsibility among the other maintainers.

  ARC		   Peter Targett <peter.targett@@arc.com>
  ARM		   Nick Clifton <nickc@@redhat.com>
  ARM		   Richard Earnshaw <rearnsha@@arm.com>
  AVR		   Denis Chertykov <denisc@@overta.ru>
  CRIS		   Hans-Peter Nilsson <hp@@axis.com>
  DWARF2	   Jason Merrill <jason@@redhat.com>
  HPPA elf32	   Alan Modra <amodra@@bigpond.net.au>
  IA64		   Jim Wilson <wilson@@redhat.com>
  x86_64	   Jan Hubicka <jh@@suse.cz>
  x86_64	   Andreas Jaeger <aj@@suse.de>
  i860		   Jason Eckhardt <jle@@redhat.com>
  ix86		   Alan Modra <amodra@@bigpond.net.au>
  ix86 COFF,PE	   DJ Delorie <dj@@redhat.com>
  ix86		   H.J.Lu <hjl@@gnu.org>
  ix86 INTEL MODE  Diego Novillo <dnovillo@@redhat.com>
  M68HC11 M68HC12  Stephane Carrez <Stephane.Carrez@@worldnet.fr>
  MN10300	   Eric Christopher <echristo@@redhat.com>
  MN10300	   Alexandre Oliva <aoliva@@redhat.com>
  MIPS		   Eric Christopher <echristo@@redhat.com>
  M88k		   Ben Elliston <bje@@redhat.com>
  MMIX		   Hans-Peter Nilsson <hp@@bitrange.com>
  PPC		   Geoff Keating <geoffk@@redhat.com>
  PPC XCOFF	   Tom Rix <trix@@redhat.com>
  s390, s390x	   Martin Schwidefsky <schwidefsky@@de.ibm.com>
  SH		   Jrn Rennecke <joern.rennecke@@superh.com>
  SH		   Hans-Peter Nilsson <hp@@bitrange.com>
  SH		   Alexandre Oliva <aoliva@@redhat.com>
  SPARC		   Jakub Jelinek <jakub@@redhat.com>
  TIC54X           Timothy Wall <twall@@alum.mit.edu>
  z8k		   Christian Groessler <chris@@groessler.org>
d57 1
a57 2

      --------- CGEN Maintainers -------------
d60 4
a63 4
disassemblers and simulators from a single description of a CPU.
It creates files in several of the binutils directories, but it
is mentioned here since there is a single group that maintains
CGEN and the files that it creates. 
d67 1
a67 1
   cgen@@sources.redhat.com
d73 1
a73 1
     --------- Write After Approval ---------
d80 2
a81 2
 *ability* to do binutils checkins, you're in this group.  Just
 remember to get approval before checking anything in.]
d83 1
a83 1
     -------------  Obvious Fixes -------------
a92 12

    --------- 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>
@


