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.ac, 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 Patches to the libiberty sources should be sent to
31 gcc-patches@gcc.gnu.org.
33 --------- Blanket Write Privs ---------
35 The following people have permission to check patches into the
36 repository without obtaining approval first:
38 Nick Clifton <nickc@redhat.com> (head maintainer)
39 Ian Lance Taylor <ian@airs.com>
40 Jeff Law <law@redhat.com>
41 Jim Wilson <wilson@tuliptree.org>
42 DJ Delorie <dj@redhat.com>
43 Alan Modra <amodra@gmail.com>
44 Michael Meissner <gnu@the-meissners.org>
45 Richard Sandiford <rdsandiford@googlemail.com>
46 Jan Beulich <jbeulich@suse.com>
48 --------- Maintainers ---------
50 Maintainers are individuals who are responsible for, and have
51 permission to check in changes in, certain subsets of the code. Note
52 that maintainers still need approval to check in changes outside of
53 the immediate domain that they maintain.
55 If there is no maintainer for a given domain then the responsibility
56 falls to the head maintainer (above). If there are several
57 maintainers for a given domain then responsibility falls to the first
58 maintainer. The first maintainer is free to devolve that
59 responsibility among the other maintainers.
61 AARCH64 Richard Earnshaw <rearnsha@arm.com>
62 AARCH64 Marcus Shawcroft <marcus.shawcroft@arm.com>
63 ARC Claudiu Zissulescu <claziss@synopsys.com>
64 ARM Nick Clifton <nickc@redhat.com>
65 ARM Richard Earnshaw <rearnsha@arm.com>
66 ARM Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
67 AVR Denis Chertykov <chertykov@gmail.com>
68 AVR Marek Michalkiewicz <marekm@amelek.gda.pl>
69 BFIN Jie Zhang <jzhang918@gmail.com>
70 BFIN Mike Frysinger <vapier@gentoo.org>
71 BPF Jose E. Marchesi <jose.marchesi@oracle.com>
72 CR16 M R Swami Reddy <MR.Swami.Reddy@nsc.com>
73 CRIS Hans-Peter Nilsson <hp@axis.com>
74 CRX M R Swami Reddy <MR.Swami.Reddy@nsc.com>
75 CTF Nick Alcock <nick.alcock@oracle.com>
76 C-SKY Lifang Xia <lifang_xia@c-sky.com>
77 C-SKY Yunhai Shang <yunhai_shang@c-sky.com>
78 DLX Nikolaos Kavvadias <nkavv@physics.auth.gr>
79 DWARF2 Jason Merrill <jason@redhat.com>
80 DWARF2 Jakub Jelinek <jakub@redhat.com>
81 dwarf-mode.el Tom Tromey <tom@tromey.com>
82 EPIPHANY Joern Rennecke <joern.rennecke@embecosm.com>
83 FR30 Nick Clifton <nickc@redhat.com>
84 FRV Nick Clifton <nickc@redhat.com>
85 FRV Alexandre Oliva <aoliva@sourceware.org>
86 GOLD Ian Lance Taylor <iant@google.com>
87 GOLD Cary Coutant <ccoutant@gmail.com>
88 gprofng Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
89 H8300 Prafulla Thakare <prafulla.thakare@kpitcummins.com>
90 HPPA Dave Anglin <dave.anglin@bell.net>
91 HPPA elf32 Alan Modra <amodra@gmail.com>
92 HPPA elf64 Jeff Law <law@redhat.com> [Basic maintainance only]
93 IA-64 Jim Wilson <wilson@tuliptree.org>
94 IQ2000 Stan Cox <scox@redhat.com>
95 ix86 H.J. Lu <hjl.tools@gmail.com>
96 ix86 COFF DJ Delorie <dj@redhat.com>
97 ix86 PE/COFF Dave Korn <dave.korn.cygwin@gmail.com>
98 ix86 INTEL MODE Jan Beulich <jbeulich@suse.com>
99 LM32 Jon Beniston <jon@beniston.com>
100 LoongArch Chenghua Xu <xuchenghua@loongson.cn>
101 LoongArch Zhensong Liu <liuzhensong@loongson.cn>
102 M32R Doug Evans <dje@sebabeach.org>
103 M68HC11 M68HC12 Stephane Carrez <Stephane.Carrez@gmail.com>
104 M68HC11 M68HC12 Sean Keys <skeys@ipdatasys.com>
105 MACH-O Tristan Gingold <tgingold@free.fr>
106 MAXQ Inderpreet Singh <inderpreetb@noida.hcltech.com>
107 MEP Nick Clifton <nickc@redhat.com>
108 METAG Markos Chandras <markos.chandras@imgtec.com>
109 MICROBLAZE Michael Eager <eager@eagercon.com>
110 MIPS Chenghua Xu <paul.hua.gm@gmail.com>
111 MIPS I-IV Maciej W. Rozycki <macro@orcam.me.uk>
112 MMIX Hans-Peter Nilsson <hp@bitrange.com>
113 MN10300 Alexandre Oliva <aoliva@sourceware.org>
114 Moxie Anthony Green <green@moxielogic.com>
115 MSP430 Dmitry Diky <diwil@spec.ru>
116 NDS32 Kuan-Lin Chen <kuanlinchentw@gmail.com>
117 NDS32 Wei-Cheng Wang <cole945@gmail.com>
118 NetBSD support Matt Thomas <matt@netbsd.org>
119 Nios II Sandra Loosemore <sandra@codesourcery.com>
120 Nios II Andrew Jenner <andrew@codesourcery.com>
121 OR1K Christian Svensson <blue@cmd.nu>
122 OR1K Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
123 OR1K Stafford Horne <shorne@gmail.com>
124 PDP11 Stephen Casner <casner@acm.org>
125 PPC Geoff Keating <geoffk@geoffk.org>
126 PPC Alan Modra <amodra@gmail.com>
127 PPC Peter Bergner <bergner@vnet.ibm.com>
128 PPC vector ext Aldy Hernandez <aldyh@redhat.com>
129 RISC-V Palmer Dabbelt <palmer@dabbelt.com>
130 RISC-V Andrew Waterman <andrew@sifive.com>
131 RISC-V Jim Wilson <jim.wilson.gcc@gmail.com>
132 RISC-V Nelson Chu <nelson.chu@sifive.com>
133 RX Nick Clifton <nickc@redhat.com>
134 S12Z John Darrington <john@darrington.wattle.id.au>
135 s390, s390x Andreas Krebbel <krebbel@linux.ibm.com>
136 SH Alexandre Oliva <aoliva@sourceware.org>
137 SPARC David S. Miller <davem@davemloft.net>
138 SPARC Jose E. Marchesi <jose.marchesi@oracle.com>
139 SPU Alan Modra <amodra@gmail.com>
140 TIC54X Timothy Wall <twall@alum.mit.edu>
141 TIC6X Joseph Myers <joseph@codesourcery.com>
142 TILE-Gx Walter Lee <walt@tilera.com>
143 TILEPro Walter Lee <walt@tilera.com>
144 VAX Matt Thomas <matt@netbsd.org>
145 VAX Jan-Benedict Glaw <jbglaw@lug-owl.de>
146 Visium Eric Botcazou <ebotcazou@libertysurf.fr>
147 VMS Tristan Gingold <tgingold@free.fr>
148 x86_64 Jan Hubicka <jh@suse.cz>
149 x86_64 Andreas Jaeger <aj@suse.de>
150 x86_64 H.J. Lu <hjl.tools@gmail.com>
151 XCOFF Richard Sandiford <r.sandiford@uk.ibm.com>
152 XGATE Sean Keys <skeys@ipdatasys.com>
153 Xtensa Max Filippov <jcmvbkbc@gmail.com>
154 Xtensa Sterling Augustine <augustine.sterling@gmail.com>
155 z8k Christian Groessler <chris@groessler.org>
157 --------- Past Maintainers -------------
159 These folks have acted as maintainers in the past, but have now
160 moved on to other things. Our thanks for all their hard work
174 --------- CGEN Maintainers -------------
176 CGEN is a tool for building, amongst other things, assemblers,
177 disassemblers and simulators from a single description of a CPU.
178 It creates files in several of the binutils directories, but it
179 is mentioned here since there is a single group that maintains
180 CGEN and the files that it creates.
182 If you have CGEN related problems you can send email to;
186 The current CGEN maintainers are:
188 Doug Evans, Frank Eigler
190 --------- Write After Approval ---------
192 Individuals with "write after approval" have the ability to check in
193 changes, but they must get approval for each change from someone in
194 one of the above lists (blanket write or maintainers).
196 [It's a huge list, folks. You know who you are. If you have the
197 *ability* to do binutils checkins, you're in this group. Just
198 remember to get approval before checking anything in.]
200 ------------- Obvious Fixes -------------
202 Fixes for obvious mistakes do not need approval, and can be checked in
203 right away, but the patch should still be sent to the binutils list.
204 The definition of obvious is a bit hazy, and if you are not sure, then
205 you should seek approval first. Obvious fixes include fixes for
206 spelling mistakes, blatantly incorrect code (where the correct code is
207 also blatantly obvious), and so on. Obvious fixes should always be
208 small, the larger they are, the more likely it is that they contain
209 some un-obvious side effect or consequence.
211 --------- Branch Checkins ---------
213 If a patch is approved for check in to the mainline sources, it can
214 also be checked into the current release branch. Normally however
215 only bug fixes should be applied to the branch. New features, new
216 ports, etc, should be restricted to the mainline. (Otherwise the
217 burden of maintaining the branch in sync with the mainline becomes too
218 great). If you are uncertain as to whether a patch is appropriate for
219 the branch, ask the branch maintainer. This is:
221 (cf global maintainers)
223 -------- Testsuites ---------------
225 In general patches to any of the binutils testsuites should be
226 considered generic and sent to the binutils mailing list for
227 approval. Patches to target specific tests are the responsibility the
228 relevant port maintainer(s), and can be approved/checked in by them.
229 Other testsuite patches need the approval of a blanket-write-priveleges
232 -------- Configure patches ----------
234 Patches to the top level configure files (config.sub & config.guess)
235 are not the domain of the binutils project and they cannot be approved
236 by the binutils group. Instead they should be submitted to the config
239 config-patches@gnu.org
241 --------- Creating Branches ---------
243 Anyone with at least write-after-approval access may create a branch
244 to use for their own development purposes. In keeping with FSF
245 policies, all patches applied to such a branch must come from people
246 with appropriate copyright assignments on file. All legal
247 requirements that would apply to any other contribution apply equally
248 to contributions on a branch.
250 Before creating the branch, you should select a name for the branch of
253 binutils-<org>-<name>
255 where "org" is the initials of your organization, or your own initials
256 if you are acting as an individual. For example, for a branch created
257 by The GNUDist Company, "tgc" would be an appropriate choice for
258 "org". It's up to each organization to select an appropriate choice
259 for "name"; some organizations may use more structure than others, so
260 "name" may contain additional hyphens.
262 Suppose that The GNUDist Company was creating a branch to develop a
263 port of Binutils to the FullMonty processor. Then, an appropriate
264 choice of branch name would be:
268 A date stamp is not required as part of the name field, but some
269 organizations like to have one. If you do include the date, you
270 should follow these rules:
272 1. The date should be the date that the branch was created.
274 2. The date should be numerical and in the form YYYYMMDD.
278 binutils-tgc-fm_20050101
280 would be appropriate if the branch was created on January 1st, 2005.
282 Having selected the branch name, create the branch as follows:
284 1. Check out binutils, so that you have a git checkout corresponding
285 to the initial state of your branch.
289 git tag binutils-<org>-<name>-branchpoint
291 That tag will allow you, and others, to easily determine what's
292 changed on the branch relative to the initial state.
294 3. Create and push the branch:
296 git checkout -b binutils-<org>-<name>-branch
299 4. Document the branch:
301 Add a description of the branch to binutils/BRANCHES, and check
302 that file in. All branch descriptions should be added to the
303 HEAD revision of the file; it doesn't help to modify
304 binutils/BRANCHES on a branch!
306 Please do not commit any patches to a branch you did not create
307 without the explicit permission of the person who created the branch.
309 Copyright (C) 2012-2022 Free Software Foundation, Inc.
311 Copying and distribution of this file, with or without modification,
312 are permitted in any medium without royalty provided the copyright
313 notice and this notice are preserved.
projects / binutils-gdb.git / blob