and patches should be sent to:
- bug-binutils@gnu.org
+ bug-binutils@gnu.org or binutils@sources.redhat.com
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:
config-patches@gnu.org
-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 (gcc-patches@gcc.gnu.org and
+gdb-patches@sources.redhat.com).
--------- Blanket Write Privs ---------
Nick Clifton <nickc@redhat.com> (head maintainer)
Richard Henderson <rth@redhat.com>
- Ian Taylor <ian@zembu.com>
+ Ian Lance Taylor <ian@airs.com>
Jeff Law <law@redhat.com>
- Jim Wilson <wilson@redhat.com>
+ Jim Wilson <wilson@specifixinc.com>
DJ Delorie <dj@redhat.com>
Alan Modra <amodra@bigpond.net.au>
- Michael Meissner <meissner@redhat.com>
+ Michael Meissner <gnu@the-meissners.org>
+ Daniel Jacobowitz <dan@debian.org>
--------- Maintainers ---------
maintainer. The first maintainer is free to devolve that
responsibility among the other maintainers.
- ARC Peter Targett <peter.targett@arc.com>
+ ALPHA Richard Henderson <rth@redhat.com>
ARM Nick Clifton <nickc@redhat.com>
ARM Richard Earnshaw <rearnsha@arm.com>
+ ARM (Symbian) 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>
+ 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>
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>
- IA64 Jim Wilson <wilson@redhat.com>
- i860 Jason Eckhardt <jle@redhat.com>
+ 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 COFF,PE DJ Delorie <dj@redhat.com>
+ 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>
+ ix86 INTEL MODE Jan Beulich <jbeulich@novell.com>
M68HC11 M68HC12 Stephane Carrez <stcarrez@nerim.fr>
- M88k Ben Elliston <bje@redhat.com>
+ M68k Ben Elliston <bje@gnu.org>
+ M88k Mark Kettenis <kettenis@gnu.org>
+ MAXQ Inderpreet Singh <inderpreetb@noida.hcltech.com>
MIPS Eric Christopher <echristo@redhat.com>
+ MIPS Thiemo Seufer <ths@networkno.de>
MMIX Hans-Peter Nilsson <hp@bitrange.com>
MN10300 Eric Christopher <echristo@redhat.com>
MN10300 Alexandre Oliva <aoliva@redhat.com>
- PPC Geoff Keating <geoffk@redhat.com>
- PPC XCOFF Tom Rix <trix@redhat.com>
+ MSP430 Dmitry Diky <diwil@spec.ru>
+ PPC Geoff Keating <geoffk@geoffk.org>
+ PPC vector ext Aldy Hernandez <aldyh@redhat.com>
s390, s390x Martin Schwidefsky <schwidefsky@de.ibm.com>
SH Jörn Rennecke <joern.rennecke@superh.com>
- SH Hans-Peter Nilsson <hp@bitrange.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@dev.seldal.com>
TIC54X Timothy Wall <twall@alum.mit.edu>
- VAX Jason R Thorpe <thorpej@wasabisystems.com>
+ VAX Jason R Thorpe <thorpej@netbsd.org>
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>
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.