1 ========= Binutils Maintainers =========
3 This is the list of individuals responsible for maintenance and update
4 of the GNU Binary Utilities project. This includes the linker (ld),
5 the assembler (gas), the profiler (gprof), a whole suite of other
6 programs (binutils) and the libraries that they use (bfd and
7 opcodes). This project shares a common set of header files with the
8 GCC and GDB projects (include), so maintainership of those files is
9 shared amoungst the projects.
11 The home page for binutils is:
13 http://www.gnu.org/software/binutils/binutils.html
15 and patches should be sent to:
17 binutils@sourceware.org
19 with "[Patch]" as part of the subject line. Note - patches to the
20 top level config.guess and config.sub scripts should be sent to:
22 config-patches@gnu.org
24 and not to the binutils lists. Patches to the other top level
25 configure files (configure, configure.in, config-ml.in) should
26 be sent to the binutils lists, and copied to the gcc and gdb
27 lists as well (gcc-patches@gcc.gnu.org and
28 gdb-patches@sourceware.org).
30 --------- Blanket Write Privs ---------
32 The following people have permission to check patches into the
33 repository without obtaining approval first:
35 Nick Clifton <nickc@redhat.com> (head maintainer)
36 Richard Henderson <rth@redhat.com>
37 Ian Lance Taylor <ian@airs.com>
38 Jeff Law <law@redhat.com>
39 Jim Wilson <wilson@tuliptree.org>
40 DJ Delorie <dj@redhat.com>
41 Alan Modra <amodra@gmail.com>
42 Michael Meissner <gnu@the-meissners.org>
43 Daniel Jacobowitz <drow@false.org>
44 Richard Sandiford <rdsandiford@googlemail.com>
46 --------- Maintainers ---------
48 Maintainers are individuals who are responsible for, and have
49 permission to check in changes in, certain subsets of the code. Note
50 that maintainers still need approval to check in changes outside of
51 the immediate domain that they maintain.
53 If there is no maintainer for a given domain then the responsibility
54 falls to the head maintainer (above). If there are several
55 maintainers for a given domain then responsibility falls to the first
56 maintainer. The first maintainer is free to devolve that
57 responsibility among the other maintainers.
59 ALPHA Richard Henderson <rth@redhat.com>
60 AARCH64 Richard Earnshaw <rearnsha@arm.com>
61 ARM Nick Clifton <nickc@redhat.com>
62 ARM Richard Earnshaw <rearnsha@arm.com>
63 ARM Paul Brook <paul@codesourcery.com>
64 ARM (Symbian) Mark Mitchell <mark@codesourcery.com>
65 AVR Denis Chertykov <denisc@overta.ru>
66 AVR Marek Michalkiewicz <marekm@amelek.gda.pl>
67 BFIN Jie Zhang <jzhang918@gmail.com>
68 BFIN Bernd Schmidt <bernd.schmidt@analog.com>
69 BFIN Mike Frysinger <michael.frysinger@analog.com>
70 BUILD SYSTEM Daniel Jacobowitz <drow@false.org>
71 CR16 M R Swami Reddy <MR.Swami.Reddy@nsc.com>
72 CRIS Hans-Peter Nilsson <hp@axis.com>
73 CRX M R Swami Reddy <MR.Swami.Reddy@nsc.com>
74 DLX Nikolaos Kavvadias <nkavv@physics.auth.gr>
75 DWARF2 Jason Merrill <jason@redhat.com>
76 DWARF2 Jakub Jelinek <jakub@redhat.com>
77 EPIPHANY Joern Rennecke <joern.rennecke@embecosm.com>
78 FR30 Dave Brolley <brolley@redhat.com>
79 FRV Dave Brolley <brolley@redhat.com>
80 FRV Alexandre Oliva <aoliva@redhat.com>
81 H8300 Prafulla Thakare <prafulla.thakare@kpitcummins.com>
82 HPPA Dave Anglin <dave.anglin@nrc.ca>
83 HPPA elf32 Alan Modra <amodra@gmail.com>
84 HPPA elf64 Jeff Law <law@redhat.com> [Basic maintainance only]
85 IA-64 Jim Wilson <wilson@tuliptree.org>
86 IQ2000 Stan Cox <scox@redhat.com>
87 i860 Jason Eckhardt <jle@rice.edu>
88 ix86 H.J. Lu <hjl.tools@gmail.com>
89 ix86 PE Christopher Faylor <me+binutils@cgf.cx>
90 ix86 COFF DJ Delorie <dj@redhat.com>
91 ix86 PE/COFF Dave Korn <dave.korn.cygwin@gmail.com>
92 ix86 INTEL MODE Jan Beulich <jbeulich@novell.com>
93 LM32 Jon Beniston <jon@beniston.com>
94 M32R Doug Evans <dje@sebabeach.org>
95 M68HC11 M68HC12 Stephane Carrez <stcarrez@nerim.fr>
96 M68HC11 M68HC12 Sean Keys <skeys@ipdatasys.com>
97 M88k Mark Kettenis <kettenis@gnu.org>
98 MACH-O Tristan Gingold <gingold@adacore.com>
99 MAXQ Inderpreet Singh <inderpreetb@noida.hcltech.com>
100 MEP Dave Brolley <brolley@redhat.com>
101 MICROBLAZE Michael Eager <eager@eagercon.com>
102 MIPS Eric Christopher <echristo@apple.com>
103 MMIX Hans-Peter Nilsson <hp@bitrange.com>
104 MN10300 Eric Christopher <echristo@apple.com>
105 MN10300 Alexandre Oliva <aoliva@redhat.com>
106 Moxie Anthony Green <green@moxielogic.com>
107 MSP430 Dmitry Diky <diwil@spec.ru>
108 NetBSD support Matt Thomas <matt@netbsd.org>
109 PPC Geoff Keating <geoffk@geoffk.org>
110 PPC Alan Modra <amodra@gmail.com>
111 PPC vector ext Aldy Hernandez <aldyh@redhat.com>
112 RL78 DJ Delorie <dj@redhat.com>
113 RX DJ Delorie <dj@redhat.com>
114 RX Nick Clifton <nickc@redhat.com>
115 s390, s390x Martin Schwidefsky <schwidefsky@de.ibm.com>
116 SCORE Mei Ligang <ligang@sunnorth.com.cn>
117 SH Alexandre Oliva <aoliva@redhat.com>
118 SH Kaz Kojima <kkojima@rr.iij4u.or.jp>
119 SPARC David S. Miller <davem@davemloft.net>
120 SPU Alan Modra <amodra@gmail.com>
121 TIC4X Svein Seldal <svein@dev.seldal.com>
122 TIC54X Timothy Wall <twall@alum.mit.edu>
123 TIC6X Joseph Myers <joseph@codesourcery.com>
124 TILE-Gx Walter Lee <walt@tilera.com>
125 TILEPro Walter Lee <walt@tilera.com>
126 VAX Matt Thomas <matt@netbsd.org>
127 VAX Jan-Benedict Glaw <jbglaw@lug-owl.de>
128 VMS Tristan Gingold <gingold@adacore.com>
129 x86_64 Jan Hubicka <jh@suse.cz>
130 x86_64 Andreas Jaeger <aj@suse.de>
131 x86_64 H.J. Lu <hjl.tools@gmail.com>
132 XCOFF Richard Sandiford <r.sandiford@uk.ibm.com>
133 XGATE Sean Keys <skeys@ipdatasys.com>
134 Xtensa Sterling Augustine <augustine.sterling@gmail.com>
135 z80 Arnold Metselaar <arnold.metselaar@planet.nl>
136 z8k Christian Groessler <chris@groessler.org>
139 --------- CGEN Maintainers -------------
141 CGEN is a tool for building, amongst other things, assemblers,
142 disassemblers and simulators from a single description of a CPU.
143 It creates files in several of the binutils directories, but it
144 is mentioned here since there is a single group that maintains
145 CGEN and the files that it creates.
147 If you have CGEN related problems you can send email to;
151 The current CGEN maintainers are:
153 Doug Evans, Frank Eigler
155 --------- Write After Approval ---------
157 Individuals with "write after approval" have the ability to check in
158 changes, but they must get approval for each change from someone in
159 one of the above lists (blanket write or maintainers).
161 [It's a huge list, folks. You know who you are. If you have the
162 *ability* to do binutils checkins, you're in this group. Just
163 remember to get approval before checking anything in.]
165 ------------- Obvious Fixes -------------
167 Fixes for obvious mistakes do not need approval, and can be checked in
168 right away, but the patch should still be sent to the binutils list.
169 The definition of obvious is a bit hazy, and if you are not sure, then
170 you should seek approval first. Obvious fixes include fixes for
171 spelling mistakes, blatantly incorrect code (where the correct code is
172 also blatantly obvious), and so on. Obvious fixes should always be
173 small, the larger they are, the more likely it is that they contain
174 some un-obvious side effect or consequence.
176 --------- Branch Checkins ---------
178 If a patch is approved for check in to the mainline sources, it can
179 also be checked into the current release branch. Normally however
180 only bug fixes should be applied to the branch. New features, new
181 ports, etc, should be restricted to the mainline. (Otherwise the
182 burden of maintaining the branch in sync with the mainline becomes too
183 great). If you are uncertain as to whether a patch is appropriate for
184 the branch, ask the branch maintainer. This is:
186 Tristan Gingold <gingold@adacore.com>
188 -------- Testsuites ---------------
190 In general patches to any of the binutils testsuites should be
191 considered generic and sent to the binutils mailing list for
192 approval. Patches to target specific tests are the responsibility the
193 relevent port maintainer(s), and can be approved/checked in by them.
194 Other testsuite patches need the approval of a blanket-write-priveleges
197 -------- Configure patches ----------
199 Patches to the top level configure files (config.sub & config.guess)
200 are not the domain of the binutils project and they cannot be approved
201 by the binutils group. Instead they should be submitted to the config
204 config-patches@gnu.org
206 --------- Creating Branches ---------
208 Anyone with at least write-after-approval access may create a branch
209 to use for their own development purposes. In keeping with FSF
210 policies, all patches applied to such a branch must come from people
211 with appropriate copyright assignments on file. All legal
212 requirements that would apply to any other contribution apply equally
213 to contributions on a branch.
215 Before creating the branch, you should select a name for the branch of
218 binutils-<org>-<name>
220 where "org" is the initials of your organization, or your own initials
221 if you are acting as an individual. For example, for a branch created
222 by The GNUDist Company, "tgc" would be an appropriate choice for
223 "org". It's up to each organization to select an appropriate choice
224 for "name"; some organizations may use more structure than others, so
225 "name" may contain additional hyphens.
227 Suppose that The GNUDist Company was creating a branch to develop a
228 port of Binutils to the FullMonty processor. Then, an appropriate
229 choice of branch name would be:
233 A date stamp is not required as part of the name field, but some
234 organizations like to have one. If you do include the date, you
235 should follow these rules:
237 1. The date should be the date that the branch was created.
239 2. The date should be numerical and in the form YYYYMMDD.
243 binutils-tgc-fm_20050101
245 would be appropriate if the branch was created on January 1st, 2005.
247 Having selected the branch name, create the branch as follows:
249 1. Check out binutils, so that you have a CVS checkout corresponding
250 to the initial state of your branch.
254 cvs tag binutils-<org>-<name>-branchpoint
256 That tag will allow you, and others, to easily determine what's
257 changed on the branch relative to the initial state.
259 3. Create the branch:
261 cvs rtag -b -r binutils-<org>-<name>-branchpoint \
262 binutils-<org>-<name>-branch
264 4. Document the branch:
266 Add a description of the branch to binutils/BRANCHES, and check
267 that file in. All branch descriptions should be added to the
268 HEAD revision of the file; it doesn't help to modify
269 binutils/BRANCHES on a branch!
271 Please do not commit any patches to a branch you did not create
272 without the explicit permission of the person who created the branch.