1 ========= Binutils Maintainers ========= 2 3This is the list of individuals responsible for maintenance and update 4of the GNU Binary Utilities project. This includes the linker (ld), 5the assembler (gas), the profiler (gprof), a whole suite of other 6programs (binutils) and the libraries that they use (bfd and 7opcodes). This project shares a common set of header files with the 8GCC and GDB projects (include), so maintainership of those files is 9shared amoungst the projects. 10 11The home page for binutils is: 12 13 http://www.gnu.org/software/binutils/binutils.html 14 15and patches should be sent to: 16 17 binutils@sourceware.org 18 19with "[Patch]" as part of the subject line. Note - patches to the 20top level config.guess and config.sub scripts should be sent to: 21 22 config-patches@gnu.org 23 24and not to the binutils lists. Patches to the other top level 25configure files (configure, configure.ac, config-ml.in) should 26be sent to the binutils lists, and copied to the gcc and gdb 27lists as well (gcc-patches@gcc.gnu.org and 28gdb-patches@sourceware.org). 29 30Patches to the libiberty sources should be sent to 31gcc-patches@gcc.gnu.org. 32 33 --------- Blanket Write Privs --------- 34 35The following people have permission to check patches into the 36repository 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 50Maintainers are individuals who are responsible for, and have 51permission to check in changes in, certain subsets of the code. Note 52that maintainers still need approval to check in changes outside of 53the immediate domain that they maintain. 54 55If there is no maintainer for a given domain then the responsibility 56falls to the head maintainer (above). If there are several 57maintainers for a given domain then responsibility falls to the first 58maintainer. The first maintainer is free to devolve that 59responsibility 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 PE Christopher Faylor <me+binutils@cgf.cx> 98 ix86 COFF DJ Delorie <dj@redhat.com> 99 ix86 PE/COFF Dave Korn <dave.korn.cygwin@gmail.com> 100 ix86 INTEL MODE Jan Beulich <jbeulich@novell.com> 101 LM32 Jon Beniston <jon@beniston.com> 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@linux-mips.org> 112 MMIX Hans-Peter Nilsson <hp@bitrange.com> 113 MN10300 Alexandre Oliva <aoliva@redhat.com> 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 PPC Geoff Keating <geoffk@geoffk.org> 124 PPC Alan Modra <amodra@gmail.com> 125 PPC Peter Bergner <bergner@vnet.ibm.com> 126 PPC vector ext Aldy Hernandez <aldyh@redhat.com> 127 RISC-V Palmer Dabbelt <palmer@dabbelt.com> 128 RISC-V Andrew Waterman <andrew@sifive.com> 129 RISC-V Jim Wilson <jimw@sifive.com> 130 RX Nick Clifton <nickc@redhat.com> 131 S12Z John Darrington <john@darrington.wattle.id.au> 132 s390, s390x Martin Schwidefsky <schwidefsky@de.ibm.com> 133 s390, s390x Andreas Krebbel <krebbel@linux.vnet.ibm.com> 134 SH Alexandre Oliva <aoliva@redhat.com> 135 SPARC David S. Miller <davem@davemloft.net> 136 SPARC Jose E. Marchesi <jose.marchesi@oracle.com> 137 SPU Alan Modra <amodra@gmail.com> 138 TIC54X Timothy Wall <twall@alum.mit.edu> 139 TIC6X Joseph Myers <joseph@codesourcery.com> 140 TILE-Gx Walter Lee <walt@tilera.com> 141 TILEPro Walter Lee <walt@tilera.com> 142 VAX Matt Thomas <matt@netbsd.org> 143 VAX Jan-Benedict Glaw <jbglaw@lug-owl.de> 144 Visium Eric Botcazou <ebotcazou@libertysurf.fr> 145 VMS Tristan Gingold <tgingold@free.fr> 146 x86_64 Jan Hubicka <jh@suse.cz> 147 x86_64 Andreas Jaeger <aj@suse.de> 148 x86_64 H.J. Lu <hjl.tools@gmail.com> 149 XCOFF Richard Sandiford <r.sandiford@uk.ibm.com> 150 XGATE Sean Keys <skeys@ipdatasys.com> 151 Xtensa Sterling Augustine <augustine.sterling@gmail.com> 152 z8k Christian Groessler <chris@groessler.org> 153 154 --------- Past Maintainers ------------- 155 156These folks have acted as maintainers in the past, but have now 157moved on to other things. Our thanks for all their hard work 158goes with them. 159 160 Paul Brook 161 Eric Christopher 162 Jason Eckhardt 163 Mark Kettenis 164 Mei Ligang 165 Arnold Metselaar 166 Mark Mitchell 167 Bernd Schmidt 168 Svein Seldal 169 170 --------- CGEN Maintainers ------------- 171 172CGEN is a tool for building, amongst other things, assemblers, 173disassemblers and simulators from a single description of a CPU. 174It creates files in several of the binutils directories, but it 175is mentioned here since there is a single group that maintains 176CGEN and the files that it creates. 177 178If you have CGEN related problems you can send email to; 179 180 cgen@sourceware.org 181 182The current CGEN maintainers are: 183 184 Doug Evans, Frank Eigler 185 186 --------- Write After Approval --------- 187 188Individuals with "write after approval" have the ability to check in 189changes, but they must get approval for each change from someone in 190one of the above lists (blanket write or maintainers). 191 192[It's a huge list, folks. You know who you are. If you have the 193 *ability* to do binutils checkins, you're in this group. Just 194 remember to get approval before checking anything in.] 195 196 ------------- Obvious Fixes ------------- 197 198Fixes for obvious mistakes do not need approval, and can be checked in 199right away, but the patch should still be sent to the binutils list. 200The definition of obvious is a bit hazy, and if you are not sure, then 201you should seek approval first. Obvious fixes include fixes for 202spelling mistakes, blatantly incorrect code (where the correct code is 203also blatantly obvious), and so on. Obvious fixes should always be 204small, the larger they are, the more likely it is that they contain 205some un-obvious side effect or consequence. 206 207 --------- Branch Checkins --------- 208 209If a patch is approved for check in to the mainline sources, it can 210also be checked into the current release branch. Normally however 211only bug fixes should be applied to the branch. New features, new 212ports, etc, should be restricted to the mainline. (Otherwise the 213burden of maintaining the branch in sync with the mainline becomes too 214great). If you are uncertain as to whether a patch is appropriate for 215the branch, ask the branch maintainer. This is: 216 217 (cf global maintainers) 218 219 -------- Testsuites --------------- 220 221In general patches to any of the binutils testsuites should be 222considered generic and sent to the binutils mailing list for 223approval. Patches to target specific tests are the responsibility the 224relevant port maintainer(s), and can be approved/checked in by them. 225Other testsuite patches need the approval of a blanket-write-priveleges 226person. 227 228 -------- Configure patches ---------- 229 230Patches to the top level configure files (config.sub & config.guess) 231are not the domain of the binutils project and they cannot be approved 232by the binutils group. Instead they should be submitted to the config 233maintainer at: 234 235 config-patches@gnu.org 236 237 --------- Creating Branches --------- 238 239Anyone with at least write-after-approval access may create a branch 240to use for their own development purposes. In keeping with FSF 241policies, all patches applied to such a branch must come from people 242with appropriate copyright assignments on file. All legal 243requirements that would apply to any other contribution apply equally 244to contributions on a branch. 245 246Before creating the branch, you should select a name for the branch of 247the form: 248 249 binutils-<org>-<name> 250 251where "org" is the initials of your organization, or your own initials 252if you are acting as an individual. For example, for a branch created 253by The GNUDist Company, "tgc" would be an appropriate choice for 254"org". It's up to each organization to select an appropriate choice 255for "name"; some organizations may use more structure than others, so 256"name" may contain additional hyphens. 257 258Suppose that The GNUDist Company was creating a branch to develop a 259port of Binutils to the FullMonty processor. Then, an appropriate 260choice of branch name would be: 261 262 binutils-tgc-fm 263 264A date stamp is not required as part of the name field, but some 265organizations like to have one. If you do include the date, you 266should follow these rules: 267 2681. The date should be the date that the branch was created. 269 2702. The date should be numerical and in the form YYYYMMDD. 271 272For example: 273 274 binutils-tgc-fm_20050101 275 276would be appropriate if the branch was created on January 1st, 2005. 277 278Having selected the branch name, create the branch as follows: 279 2801. Check out binutils, so that you have a git checkout corresponding 281 to the initial state of your branch. 282 2832. Create a tag: 284 285 git tag binutils-<org>-<name>-branchpoint 286 287 That tag will allow you, and others, to easily determine what's 288 changed on the branch relative to the initial state. 289 2903. Create and push the branch: 291 292 git checkout -b binutils-<org>-<name>-branch 293 git push origin HEAD 294 2954. Document the branch: 296 297 Add a description of the branch to binutils/BRANCHES, and check 298 that file in. All branch descriptions should be added to the 299 HEAD revision of the file; it doesn't help to modify 300 binutils/BRANCHES on a branch! 301 302Please do not commit any patches to a branch you did not create 303without the explicit permission of the person who created the branch. 304 305Copyright (C) 2012-2020 Free Software Foundation, Inc. 306 307Copying and distribution of this file, with or without modification, 308are permitted in any medium without royalty provided the copyright 309notice and this notice are preserved. 310