Commit | Line | Data |
---|---|---|
302ab118 DD |
1 | ========= Binutils Maintainers ========= |
2 | ||
3 | This is the list of individuals responsible for maintenance and update | |
1b577b00 NC |
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 | |
eacf2b70 | 8 | GCC and GDB projects (include), so maintainership of those files is |
1b577b00 | 9 | shared amoungst the projects. |
302ab118 | 10 | |
1b577b00 | 11 | The home page for binutils is: |
8c2bc687 | 12 | |
1b577b00 NC |
13 | http://www.gnu.org/software/binutils/binutils.html |
14 | ||
15 | and patches should be sent to: | |
16 | ||
eacf2b70 AM |
17 | binutils@sourceware.org |
18 | ||
1b577b00 | 19 | with "[Patch]" as part of the subject line. Note - patches to the |
04fbe429 | 20 | top level config.guess and config.sub scripts should be sent to: |
302ab118 | 21 | |
1b577b00 | 22 | config-patches@gnu.org |
302ab118 | 23 | |
04fbe429 | 24 | and not to the binutils lists. Patches to the other top level |
bf41f30d | 25 | configure files (configure, configure.ac, config-ml.in) should |
73fb7068 | 26 | be sent to the binutils lists, and copied to the gcc and gdb |
04fbe429 | 27 | lists as well (gcc-patches@gcc.gnu.org and |
eacf2b70 | 28 | gdb-patches@sourceware.org). |
1b577b00 | 29 | |
bf41f30d NC |
30 | Patches to the libiberty sources should be sent to |
31 | gcc-patches@gcc.gnu.org. | |
32 | ||
1b577b00 | 33 | --------- Blanket Write Privs --------- |
302ab118 | 34 | |
1b577b00 NC |
35 | The following people have permission to check patches into the |
36 | repository without obtaining approval first: | |
eacf2b70 | 37 | |
1b577b00 | 38 | Nick Clifton <nickc@redhat.com> (head maintainer) |
3517749c | 39 | Ian Lance Taylor <ian@airs.com> |
1b577b00 | 40 | Jeff Law <law@redhat.com> |
4b3be0b6 | 41 | Jim Wilson <wilson@tuliptree.org> |
1b577b00 | 42 | DJ Delorie <dj@redhat.com> |
ebc5095a | 43 | Alan Modra <amodra@gmail.com> |
2445335e | 44 | Michael Meissner <gnu@the-meissners.org> |
9483a6ee | 45 | Daniel Jacobowitz <drow@false.org> |
93abc97a | 46 | Richard Sandiford <rdsandiford@googlemail.com> |
1b577b00 NC |
47 | |
48 | --------- Maintainers --------- | |
49 | ||
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. | |
302ab118 DD |
54 | |
55 | If there is no maintainer for a given domain then the responsibility | |
1b577b00 NC |
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. | |
60 | ||
2141b110 | 61 | ALPHA Richard Henderson <rth@twiddle.net> |
a06ea964 | 62 | AARCH64 Richard Earnshaw <rearnsha@arm.com> |
5b2ab150 | 63 | AARCH64 Marcus Shawcroft <marcus.shawcroft@arm.com> |
1b577b00 | 64 | ARM Nick Clifton <nickc@redhat.com> |
3a7e524e | 65 | ARM Richard Earnshaw <rearnsha@arm.com> |
6c1965f9 | 66 | ARM Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> |
e8b338d0 | 67 | AVR Denis Chertykov <chertykov@gmail.com> |
e0159aa9 | 68 | AVR Marek Michalkiewicz <marekm@amelek.gda.pl> |
4161fbb0 | 69 | BFIN Jie Zhang <jzhang918@gmail.com> |
3d5ff620 | 70 | BFIN Mike Frysinger <vapier@gentoo.org> |
9483a6ee | 71 | BUILD SYSTEM Daniel Jacobowitz <drow@false.org> |
ec8cbbf6 | 72 | CR16 M R Swami Reddy <MR.Swami.Reddy@nsc.com> |
1b577b00 | 73 | CRIS Hans-Peter Nilsson <hp@axis.com> |
ec8cbbf6 | 74 | CRX M R Swami Reddy <MR.Swami.Reddy@nsc.com> |
4b3dc01d | 75 | DLX Nikolaos Kavvadias <nkavv@physics.auth.gr> |
1b577b00 | 76 | DWARF2 Jason Merrill <jason@redhat.com> |
1cd48f98 | 77 | DWARF2 Jakub Jelinek <jakub@redhat.com> |
be459434 | 78 | dwarf-mode.el Tom Tromey <tom@tromey.com> |
5b169225 | 79 | EPIPHANY Joern Rennecke <joern.rennecke@embecosm.com> |
a9f0b5e7 DB |
80 | FR30 Dave Brolley <brolley@redhat.com> |
81 | FRV Dave Brolley <brolley@redhat.com> | |
ec2dfb42 | 82 | FRV Alexandre Oliva <aoliva@redhat.com> |
ee441d9a | 83 | GOLD Ian Lance Taylor <iant@google.com> |
08e4f608 | 84 | GOLD Cary Coutant <ccoutant@gmail.com> |
db448d50 | 85 | H8300 Prafulla Thakare <prafulla.thakare@kpitcummins.com> |
89f60df2 | 86 | HPPA Dave Anglin <dave.anglin@bell.net> |
ebc5095a | 87 | HPPA elf32 Alan Modra <amodra@gmail.com> |
f52e0eb8 | 88 | HPPA elf64 Jeff Law <law@redhat.com> [Basic maintainance only] |
4b3be0b6 | 89 | IA-64 Jim Wilson <wilson@tuliptree.org> |
3b36097d | 90 | IQ2000 Stan Cox <scox@redhat.com> |
ccdb9c9f | 91 | ix86 H.J. Lu <hjl.tools@gmail.com> |
bd5a94b0 | 92 | ix86 PE Christopher Faylor <me+binutils@cgf.cx> |
b54e7460 | 93 | ix86 COFF DJ Delorie <dj@redhat.com> |
57f6e0bc | 94 | ix86 PE/COFF Dave Korn <dave.korn.cygwin@gmail.com> |
53260797 | 95 | ix86 INTEL MODE Jan Beulich <jbeulich@novell.com> |
84e94c90 | 96 | LM32 Jon Beniston <jon@beniston.com> |
5d0c4f10 | 97 | M32R Doug Evans <dje@sebabeach.org> |
a481d14b | 98 | M68HC11 M68HC12 Stephane Carrez <Stephane.Carrez@gmail.com> |
554adb2c | 99 | M68HC11 M68HC12 Sean Keys <skeys@ipdatasys.com> |
c91933e9 | 100 | MACH-O Tristan Gingold <tgingold@free.fr> |
c4cf3821 | 101 | MAXQ Inderpreet Singh <inderpreetb@noida.hcltech.com> |
0dd5bc5e | 102 | MEP Dave Brolley <brolley@redhat.com> |
d5c7e0e9 | 103 | METAG Markos Chandras <markos.chandras@imgtec.com> |
7ba29e2a | 104 | MICROBLAZE Michael Eager <eager@eagercon.com> |
d65ce302 | 105 | MIPS Maciej W. Rozycki <macro@mips.com> |
9b19141a | 106 | MMIX Hans-Peter Nilsson <hp@bitrange.com> |
91593c9d | 107 | MN10300 Alexandre Oliva <aoliva@redhat.com> |
17eb60e9 | 108 | Moxie Anthony Green <green@moxielogic.com> |
1acfb01b | 109 | MSP430 Dmitry Diky <diwil@spec.ru> |
35c08157 KLC |
110 | NDS32 Kuan-Lin Chen <kuanlinchentw@gmail.com> |
111 | NDS32 Wei-Cheng Wang <cole945@gmail.com> | |
5ad507ee | 112 | NetBSD support Matt Thomas <matt@netbsd.org> |
36591ba1 SL |
113 | Nios II Sandra Loosemore <sandra@codesourcery.com> |
114 | Nios II Andrew Jenner <andrew@codesourcery.com> | |
b2bcb4bd CS |
115 | OR1K Christian Svensson <blue@cmd.nu> |
116 | OR1K Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> | |
a926ab2f | 117 | PPC Geoff Keating <geoffk@geoffk.org> |
ebc5095a | 118 | PPC Alan Modra <amodra@gmail.com> |
4bc0608a | 119 | PPC Peter Bergner <bergner@vnet.ibm.com> |
42ea8716 | 120 | PPC vector ext Aldy Hernandez <aldyh@redhat.com> |
180093c7 PD |
121 | RISC-V Palmer Dabbelt <palmer@sifive.com> |
122 | RISC-V Andrew Waterman <andrew@sifive.com> | |
016f5a37 | 123 | RISC-V Jim Wilson <jimw@sifive.com> |
99c513f6 | 124 | RL78 DJ Delorie <dj@redhat.com> |
c7927a3c NC |
125 | RX DJ Delorie <dj@redhat.com> |
126 | RX Nick Clifton <nickc@redhat.com> | |
54589086 | 127 | s390, s390x Martin Schwidefsky <schwidefsky@de.ibm.com> |
6604eb5f | 128 | s390, s390x Andreas Krebbel <krebbel@linux.vnet.ibm.com> |
9f77fa06 | 129 | SH Alexandre Oliva <aoliva@redhat.com> |
cdd30861 | 130 | SPARC David S. Miller <davem@davemloft.net> |
9b5481c6 | 131 | SPARC Jose E. Marchesi <jose.marchesi@oracle.com> |
ebc5095a | 132 | SPU Alan Modra <amodra@gmail.com> |
6e917903 | 133 | TIC54X Timothy Wall <twall@alum.mit.edu> |
40b36596 | 134 | TIC6X Joseph Myers <joseph@codesourcery.com> |
ab8b6d29 WL |
135 | TILE-Gx Walter Lee <walt@tilera.com> |
136 | TILEPro Walter Lee <walt@tilera.com> | |
5ad507ee | 137 | VAX Matt Thomas <matt@netbsd.org> |
677c6f3a | 138 | VAX Jan-Benedict Glaw <jbglaw@lug-owl.de> |
2a6969e1 | 139 | Visium Eric Botcazou <ebotcazou@libertysurf.fr> |
c91933e9 | 140 | VMS Tristan Gingold <tgingold@free.fr> |
91593c9d AM |
141 | x86_64 Jan Hubicka <jh@suse.cz> |
142 | x86_64 Andreas Jaeger <aj@suse.de> | |
fabda5a7 | 143 | x86_64 H.J. Lu <hjl.tools@gmail.com> |
93abc97a | 144 | XCOFF Richard Sandiford <r.sandiford@uk.ibm.com> |
8d88d7ec | 145 | XGATE Sean Keys <skeys@ipdatasys.com> |
3aade688 | 146 | Xtensa Sterling Augustine <augustine.sterling@gmail.com> |
190668a2 | 147 | z80 Arnold Metselaar <arnold.metselaar@planet.nl> |
3c25c5f6 NC |
148 | z8k Christian Groessler <chris@groessler.org> |
149 | ||
13364275 NC |
150 | --------- Past Maintainers ------------- |
151 | ||
152 | These folks have acted as maintainers in the past, but have now | |
153 | moved on to other things. Our thanks for all their hard work | |
154 | goes with them. | |
155 | ||
fd13a84b | 156 | Paul Brook |
7c723eec | 157 | Eric Christopher |
f1ca0d6d | 158 | Jason Eckhardt |
c2bf1eec | 159 | Mark Kettenis |
71d01c69 | 160 | Mei Ligang |
13364275 | 161 | Mark Mitchell |
cf581a9b | 162 | Bernd Schmidt |
482366c3 | 163 | Svein Seldal |
1b577b00 NC |
164 | |
165 | --------- CGEN Maintainers ------------- | |
dac850af | 166 | |
08c404a5 | 167 | CGEN is a tool for building, amongst other things, assemblers, |
1b577b00 NC |
168 | disassemblers and simulators from a single description of a CPU. |
169 | It creates files in several of the binutils directories, but it | |
170 | is mentioned here since there is a single group that maintains | |
eacf2b70 | 171 | CGEN and the files that it creates. |
dac850af NC |
172 | |
173 | If you have CGEN related problems you can send email to; | |
174 | ||
eacf2b70 | 175 | cgen@sourceware.org |
dac850af NC |
176 | |
177 | The current CGEN maintainers are: | |
178 | ||
b893fd29 | 179 | Doug Evans, Frank Eigler |
302ab118 | 180 | |
1b577b00 | 181 | --------- Write After Approval --------- |
302ab118 DD |
182 | |
183 | Individuals with "write after approval" have the ability to check in | |
184 | changes, but they must get approval for each change from someone in | |
185 | one of the above lists (blanket write or maintainers). | |
186 | ||
187 | [It's a huge list, folks. You know who you are. If you have the | |
1b577b00 NC |
188 | *ability* to do binutils checkins, you're in this group. Just |
189 | remember to get approval before checking anything in.] | |
a9f10786 | 190 | |
1b577b00 | 191 | ------------- Obvious Fixes ------------- |
a9f10786 NC |
192 | |
193 | Fixes for obvious mistakes do not need approval, and can be checked in | |
194 | right away, but the patch should still be sent to the binutils list. | |
195 | The definition of obvious is a bit hazy, and if you are not sure, then | |
196 | you should seek approval first. Obvious fixes include fixes for | |
197 | spelling mistakes, blatantly incorrect code (where the correct code is | |
198 | also blatantly obvious), and so on. Obvious fixes should always be | |
199 | small, the larger they are, the more likely it is that they contain | |
200 | some un-obvious side effect or consequence. | |
90ab7e9a | 201 | |
1b577b00 | 202 | --------- Branch Checkins --------- |
90ab7e9a NC |
203 | |
204 | If a patch is approved for check in to the mainline sources, it can | |
205 | also be checked into the current release branch. Normally however | |
206 | only bug fixes should be applied to the branch. New features, new | |
207 | ports, etc, should be restricted to the mainline. (Otherwise the | |
eacf2b70 | 208 | burden of maintaining the branch in sync with the mainline becomes too |
90ab7e9a NC |
209 | great). If you are uncertain as to whether a patch is appropriate for |
210 | the branch, ask the branch maintainer. This is: | |
211 | ||
c91933e9 | 212 | (cf global maintainers) |
873e0588 NC |
213 | |
214 | -------- Testsuites --------------- | |
215 | ||
216 | In general patches to any of the binutils testsuites should be | |
217 | considered generic and sent to the binutils mailing list for | |
218 | approval. Patches to target specific tests are the responsibility the | |
13364275 | 219 | relevant port maintainer(s), and can be approved/checked in by them. |
873e0588 NC |
220 | Other testsuite patches need the approval of a blanket-write-priveleges |
221 | person. | |
222 | ||
223 | -------- Configure patches ---------- | |
224 | ||
225 | Patches to the top level configure files (config.sub & config.guess) | |
226 | are not the domain of the binutils project and they cannot be approved | |
227 | by the binutils group. Instead they should be submitted to the config | |
228 | maintainer at: | |
229 | ||
230 | config-patches@gnu.org | |
619b8b60 MM |
231 | |
232 | --------- Creating Branches --------- | |
233 | ||
234 | Anyone with at least write-after-approval access may create a branch | |
235 | to use for their own development purposes. In keeping with FSF | |
236 | policies, all patches applied to such a branch must come from people | |
237 | with appropriate copyright assignments on file. All legal | |
238 | requirements that would apply to any other contribution apply equally | |
239 | to contributions on a branch. | |
240 | ||
241 | Before creating the branch, you should select a name for the branch of | |
242 | the form: | |
243 | ||
eacf2b70 | 244 | binutils-<org>-<name> |
619b8b60 MM |
245 | |
246 | where "org" is the initials of your organization, or your own initials | |
247 | if you are acting as an individual. For example, for a branch created | |
248 | by The GNUDist Company, "tgc" would be an appropriate choice for | |
249 | "org". It's up to each organization to select an appropriate choice | |
250 | for "name"; some organizations may use more structure than others, so | |
251 | "name" may contain additional hyphens. | |
252 | ||
253 | Suppose that The GNUDist Company was creating a branch to develop a | |
254 | port of Binutils to the FullMonty processor. Then, an appropriate | |
255 | choice of branch name would be: | |
256 | ||
257 | binutils-tgc-fm | |
258 | ||
45781998 | 259 | A date stamp is not required as part of the name field, but some |
619b8b60 MM |
260 | organizations like to have one. If you do include the date, you |
261 | should follow these rules: | |
262 | ||
263 | 1. The date should be the date that the branch was created. | |
264 | ||
265 | 2. The date should be numerical and in the form YYYYMMDD. | |
266 | ||
267 | For example: | |
268 | ||
269 | binutils-tgc-fm_20050101 | |
270 | ||
271 | would be appropriate if the branch was created on January 1st, 2005. | |
272 | ||
273 | Having selected the branch name, create the branch as follows: | |
274 | ||
20cef68c | 275 | 1. Check out binutils, so that you have a git checkout corresponding |
619b8b60 MM |
276 | to the initial state of your branch. |
277 | ||
278 | 2. Create a tag: | |
279 | ||
20cef68c | 280 | git tag binutils-<org>-<name>-branchpoint |
619b8b60 MM |
281 | |
282 | That tag will allow you, and others, to easily determine what's | |
283 | changed on the branch relative to the initial state. | |
284 | ||
20cef68c | 285 | 3. Create and push the branch: |
619b8b60 | 286 | |
20cef68c TT |
287 | git checkout -b binutils-<org>-<name>-branch |
288 | git push origin HEAD | |
619b8b60 MM |
289 | |
290 | 4. Document the branch: | |
291 | ||
292 | Add a description of the branch to binutils/BRANCHES, and check | |
293 | that file in. All branch descriptions should be added to the | |
294 | HEAD revision of the file; it doesn't help to modify | |
295 | binutils/BRANCHES on a branch! | |
296 | ||
297 | Please do not commit any patches to a branch you did not create | |
298 | without the explicit permission of the person who created the branch. | |
5bf135a7 | 299 | \f |
219d1afa | 300 | Copyright (C) 2012-2018 Free Software Foundation, Inc. |
5bf135a7 NC |
301 | |
302 | Copying and distribution of this file, with or without modification, | |
303 | are permitted in any medium without royalty provided the copyright | |
304 | notice and this notice are preserved. |