131 lines
5.2 KiB
Text
131 lines
5.2 KiB
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:
|
||
|
||
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.
|
||
|
||
--------- 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@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.
|
||
|
||
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.
|
||
|
||
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 J<>rn 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 <cpg@aladdin.de>
|
||
|
||
--------- 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>
|