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.in, 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 30 --------- Blanket Write Privs --------- 31 32The following people have permission to check patches into the 33repository without obtaining approval first: 34 35 Nick Clifton <nickc@redhat.com> (head maintainer) 36 Richard Henderson <rth@redhat.com> 37 Ian Lance Taylor <ian@airs.com> 38 Jeff Law <law@redhat.com> 39 Jim Wilson <wilson@tuliptree.org> 40 DJ Delorie <dj@redhat.com> 41 Alan Modra <amodra@gmail.com> 42 Michael Meissner <gnu@the-meissners.org> 43 Daniel Jacobowitz <drow@false.org> 44 Richard Sandiford <rdsandiford@googlemail.com> 45 46 --------- Maintainers --------- 47 48Maintainers are individuals who are responsible for, and have 49permission to check in changes in, certain subsets of the code. Note 50that maintainers still need approval to check in changes outside of 51the immediate domain that they maintain. 52 53If there is no maintainer for a given domain then the responsibility 54falls to the head maintainer (above). If there are several 55maintainers for a given domain then responsibility falls to the first 56maintainer. The first maintainer is free to devolve that 57responsibility among the other maintainers. 58 59 ALPHA Richard Henderson <rth@redhat.com> 60 AARCH64 Richard Earnshaw <rearnsha@arm.com> 61 AARCH64 Marcus Shawcroft <marcus.shawcroft@arm.com> 62 ARM Nick Clifton <nickc@redhat.com> 63 ARM Richard Earnshaw <rearnsha@arm.com> 64 ARM Paul Brook <paul@codesourcery.com> 65 ARM Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> 66 AVR Denis Chertykov <chertykov@gmail.com> 67 AVR Marek Michalkiewicz <marekm@amelek.gda.pl> 68 BFIN Jie Zhang <jzhang918@gmail.com> 69 BFIN Bernd Schmidt <bernd.schmidt@analog.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 EPIPHANY Joern Rennecke <joern.rennecke@embecosm.com> 79 FR30 Dave Brolley <brolley@redhat.com> 80 FRV Dave Brolley <brolley@redhat.com> 81 FRV Alexandre Oliva <aoliva@redhat.com> 82 GOLD Ian Lance Taylor <iant@google.com> 83 GOLD Cary Coutant <ccoutant@gmail.com> 84 H8300 Prafulla Thakare <prafulla.thakare@kpitcummins.com> 85 HPPA Dave Anglin <dave.anglin@nrc.ca> 86 HPPA elf32 Alan Modra <amodra@gmail.com> 87 HPPA elf64 Jeff Law <law@redhat.com> [Basic maintainance only] 88 IA-64 Jim Wilson <wilson@tuliptree.org> 89 IQ2000 Stan Cox <scox@redhat.com> 90 i860 Jason Eckhardt <jle@rice.edu> 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 M88k Mark Kettenis <kettenis@gnu.org> 101 MACH-O Tristan Gingold <gingold@adacore.com> 102 MAXQ Inderpreet Singh <inderpreetb@noida.hcltech.com> 103 MEP Dave Brolley <brolley@redhat.com> 104 METAG Markos Chandras <markos.chandras@imgtec.com> 105 MICROBLAZE Michael Eager <eager@eagercon.com> 106 MIPS Eric Christopher <echristo@apple.com> 107 MIPS Maciej W. Rozycki <macro@imgtec.com> 108 MMIX Hans-Peter Nilsson <hp@bitrange.com> 109 MN10300 Eric Christopher <echristo@apple.com> 110 MN10300 Alexandre Oliva <aoliva@redhat.com> 111 Moxie Anthony Green <green@moxielogic.com> 112 MSP430 Dmitry Diky <diwil@spec.ru> 113 NDS32 Kuan-Lin Chen <kuanlinchentw@gmail.com> 114 NDS32 Wei-Cheng Wang <cole945@gmail.com> 115 NetBSD support Matt Thomas <matt@netbsd.org> 116 Nios II Sandra Loosemore <sandra@codesourcery.com> 117 Nios II Andrew Jenner <andrew@codesourcery.com> 118 OR1K Christian Svensson <blue@cmd.nu> 119 OR1K Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> 120 PPC Geoff Keating <geoffk@geoffk.org> 121 PPC Alan Modra <amodra@gmail.com> 122 PPC Peter Bergner <bergner@vnet.ibm.com> 123 PPC vector ext Aldy Hernandez <aldyh@redhat.com> 124 RISC-V Palmer Dabbelt <palmer@dabbelt.com> 125 RISC-V Andrew Waterman <andrew@sifive.com> 126 RL78 DJ Delorie <dj@redhat.com> 127 RX DJ Delorie <dj@redhat.com> 128 RX Nick Clifton <nickc@redhat.com> 129 s390, s390x Martin Schwidefsky <schwidefsky@de.ibm.com> 130 s390, s390x Andreas Krebbel <krebbel@linux.vnet.ibm.com> 131 SCORE Mei Ligang <ligang@sunnorth.com.cn> 132 SH Alexandre Oliva <aoliva@redhat.com> 133 SH Kaz Kojima <kkojima@rr.iij4u.or.jp> 134 SPARC David S. Miller <davem@davemloft.net> 135 SPARC Jose E. Marchesi <jose.marchesi@oracle.com> 136 SPU Alan Modra <amodra@gmail.com> 137 TIC4X Svein Seldal <svein@dev.seldal.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 VMS Tristan Gingold <gingold@adacore.com> 145 x86_64 Jan Hubicka <jh@suse.cz> 146 x86_64 Andreas Jaeger <aj@suse.de> 147 x86_64 H.J. Lu <hjl.tools@gmail.com> 148 XCOFF Richard Sandiford <r.sandiford@uk.ibm.com> 149 XGATE Sean Keys <skeys@ipdatasys.com> 150 Xtensa Sterling Augustine <augustine.sterling@gmail.com> 151 z80 Arnold Metselaar <arnold.metselaar@planet.nl> 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 Mark Mitchell 161 162 --------- CGEN Maintainers ------------- 163 164CGEN is a tool for building, amongst other things, assemblers, 165disassemblers and simulators from a single description of a CPU. 166It creates files in several of the binutils directories, but it 167is mentioned here since there is a single group that maintains 168CGEN and the files that it creates. 169 170If you have CGEN related problems you can send email to; 171 172 cgen@sourceware.org 173 174The current CGEN maintainers are: 175 176 Doug Evans, Frank Eigler 177 178 --------- Write After Approval --------- 179 180Individuals with "write after approval" have the ability to check in 181changes, but they must get approval for each change from someone in 182one of the above lists (blanket write or maintainers). 183 184[It's a huge list, folks. You know who you are. If you have the 185 *ability* to do binutils checkins, you're in this group. Just 186 remember to get approval before checking anything in.] 187 188 ------------- Obvious Fixes ------------- 189 190Fixes for obvious mistakes do not need approval, and can be checked in 191right away, but the patch should still be sent to the binutils list. 192The definition of obvious is a bit hazy, and if you are not sure, then 193you should seek approval first. Obvious fixes include fixes for 194spelling mistakes, blatantly incorrect code (where the correct code is 195also blatantly obvious), and so on. Obvious fixes should always be 196small, the larger they are, the more likely it is that they contain 197some un-obvious side effect or consequence. 198 199 --------- Branch Checkins --------- 200 201If a patch is approved for check in to the mainline sources, it can 202also be checked into the current release branch. Normally however 203only bug fixes should be applied to the branch. New features, new 204ports, etc, should be restricted to the mainline. (Otherwise the 205burden of maintaining the branch in sync with the mainline becomes too 206great). If you are uncertain as to whether a patch is appropriate for 207the branch, ask the branch maintainer. This is: 208 209 Tristan Gingold <gingold@adacore.com> 210 211 -------- Testsuites --------------- 212 213In general patches to any of the binutils testsuites should be 214considered generic and sent to the binutils mailing list for 215approval. Patches to target specific tests are the responsibility the 216relevant port maintainer(s), and can be approved/checked in by them. 217Other testsuite patches need the approval of a blanket-write-priveleges 218person. 219 220 -------- Configure patches ---------- 221 222Patches to the top level configure files (config.sub & config.guess) 223are not the domain of the binutils project and they cannot be approved 224by the binutils group. Instead they should be submitted to the config 225maintainer at: 226 227 config-patches@gnu.org 228 229 --------- Creating Branches --------- 230 231Anyone with at least write-after-approval access may create a branch 232to use for their own development purposes. In keeping with FSF 233policies, all patches applied to such a branch must come from people 234with appropriate copyright assignments on file. All legal 235requirements that would apply to any other contribution apply equally 236to contributions on a branch. 237 238Before creating the branch, you should select a name for the branch of 239the form: 240 241 binutils-<org>-<name> 242 243where "org" is the initials of your organization, or your own initials 244if you are acting as an individual. For example, for a branch created 245by The GNUDist Company, "tgc" would be an appropriate choice for 246"org". It's up to each organization to select an appropriate choice 247for "name"; some organizations may use more structure than others, so 248"name" may contain additional hyphens. 249 250Suppose that The GNUDist Company was creating a branch to develop a 251port of Binutils to the FullMonty processor. Then, an appropriate 252choice of branch name would be: 253 254 binutils-tgc-fm 255 256A date stamp is not required as part of the name field, but some 257organizations like to have one. If you do include the date, you 258should follow these rules: 259 2601. The date should be the date that the branch was created. 261 2622. The date should be numerical and in the form YYYYMMDD. 263 264For example: 265 266 binutils-tgc-fm_20050101 267 268would be appropriate if the branch was created on January 1st, 2005. 269 270Having selected the branch name, create the branch as follows: 271 2721. Check out binutils, so that you have a git checkout corresponding 273 to the initial state of your branch. 274 2752. Create a tag: 276 277 git tag binutils-<org>-<name>-branchpoint 278 279 That tag will allow you, and others, to easily determine what's 280 changed on the branch relative to the initial state. 281 2823. Create and push the branch: 283 284 git checkout -b binutils-<org>-<name>-branch 285 git push origin HEAD 286 2874. Document the branch: 288 289 Add a description of the branch to binutils/BRANCHES, and check 290 that file in. All branch descriptions should be added to the 291 HEAD revision of the file; it doesn't help to modify 292 binutils/BRANCHES on a branch! 293 294Please do not commit any patches to a branch you did not create 295without the explicit permission of the person who created the branch. 296 297Copyright (C) 2012-2017 Free Software Foundation, Inc. 298 299Copying and distribution of this file, with or without modification, 300are permitted in any medium without royalty provided the copyright 301notice and this notice are preserved. 302