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