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