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 ARM (Symbian) Mark Mitchell <mark@codesourcery.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 Bernd Schmidt <bernd.schmidt@analog.com> 71 BFIN Mike Frysinger <vapier@gentoo.org> 72 BUILD SYSTEM Daniel Jacobowitz <drow@false.org> 73 CR16 M R Swami Reddy <MR.Swami.Reddy@nsc.com> 74 CRIS Hans-Peter Nilsson <hp@axis.com> 75 CRX M R Swami Reddy <MR.Swami.Reddy@nsc.com> 76 DLX Nikolaos Kavvadias <nkavv@physics.auth.gr> 77 DWARF2 Jason Merrill <jason@redhat.com> 78 DWARF2 Jakub Jelinek <jakub@redhat.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@nrc.ca> 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 i860 Jason Eckhardt <jle@rice.edu> 92 ix86 H.J. Lu <hjl.tools@gmail.com> 93 ix86 PE Christopher Faylor <me+binutils@cgf.cx> 94 ix86 COFF DJ Delorie <dj@redhat.com> 95 ix86 PE/COFF Dave Korn <dave.korn.cygwin@gmail.com> 96 ix86 INTEL MODE Jan Beulich <jbeulich@novell.com> 97 LM32 Jon Beniston <jon@beniston.com> 98 M32R Doug Evans <dje@sebabeach.org> 99 M68HC11 M68HC12 Stephane Carrez <Stephane.Carrez@gmail.com> 100 M68HC11 M68HC12 Sean Keys <skeys@ipdatasys.com> 101 M88k Mark Kettenis <kettenis@gnu.org> 102 MACH-O Tristan Gingold <gingold@adacore.com> 103 MAXQ Inderpreet Singh <inderpreetb@noida.hcltech.com> 104 MEP Dave Brolley <brolley@redhat.com> 105 METAG Markos Chandras <markos.chandras@imgtec.com> 106 MICROBLAZE Michael Eager <eager@eagercon.com> 107 MIPS Eric Christopher <echristo@apple.com> 108 MIPS Maciej W. Rozycki <macro@imgtec.com> 109 MMIX Hans-Peter Nilsson <hp@bitrange.com> 110 MN10300 Eric Christopher <echristo@apple.com> 111 MN10300 Alexandre Oliva <aoliva@redhat.com> 112 Moxie Anthony Green <green@moxielogic.com> 113 MSP430 Dmitry Diky <diwil@spec.ru> 114 NDS32 Kuan-Lin Chen <kuanlinchentw@gmail.com> 115 NDS32 Wei-Cheng Wang <cole945@gmail.com> 116 NetBSD support Matt Thomas <matt@netbsd.org> 117 Nios II Sandra Loosemore <sandra@codesourcery.com> 118 Nios II Andrew Jenner <andrew@codesourcery.com> 119 OR1K Christian Svensson <blue@cmd.nu> 120 OR1K Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> 121 PPC Geoff Keating <geoffk@geoffk.org> 122 PPC Alan Modra <amodra@gmail.com> 123 PPC Peter Bergner <bergner@vnet.ibm.com> 124 PPC vector ext Aldy Hernandez <aldyh@redhat.com> 125 RL78 DJ Delorie <dj@redhat.com> 126 RX DJ Delorie <dj@redhat.com> 127 RX Nick Clifton <nickc@redhat.com> 128 s390, s390x Martin Schwidefsky <schwidefsky@de.ibm.com> 129 s390, s390x Andreas Krebbel <krebbel@linux.vnet.ibm.com> 130 SCORE Mei Ligang <ligang@sunnorth.com.cn> 131 SH Alexandre Oliva <aoliva@redhat.com> 132 SH Kaz Kojima <kkojima@rr.iij4u.or.jp> 133 SPARC David S. Miller <davem@davemloft.net> 134 SPU Alan Modra <amodra@gmail.com> 135 TIC4X Svein Seldal <svein@dev.seldal.com> 136 TIC54X Timothy Wall <twall@alum.mit.edu> 137 TIC6X Joseph Myers <joseph@codesourcery.com> 138 TILE-Gx Walter Lee <walt@tilera.com> 139 TILEPro Walter Lee <walt@tilera.com> 140 VAX Matt Thomas <matt@netbsd.org> 141 VAX Jan-Benedict Glaw <jbglaw@lug-owl.de> 142 VMS Tristan Gingold <gingold@adacore.com> 143 x86_64 Jan Hubicka <jh@suse.cz> 144 x86_64 Andreas Jaeger <aj@suse.de> 145 x86_64 H.J. Lu <hjl.tools@gmail.com> 146 XCOFF Richard Sandiford <r.sandiford@uk.ibm.com> 147 XGATE Sean Keys <skeys@ipdatasys.com> 148 Xtensa Sterling Augustine <augustine.sterling@gmail.com> 149 z80 Arnold Metselaar <arnold.metselaar@planet.nl> 150 z8k Christian Groessler <chris@groessler.org> 151 152 153 --------- CGEN Maintainers ------------- 154 155CGEN is a tool for building, amongst other things, assemblers, 156disassemblers and simulators from a single description of a CPU. 157It creates files in several of the binutils directories, but it 158is mentioned here since there is a single group that maintains 159CGEN and the files that it creates. 160 161If you have CGEN related problems you can send email to; 162 163 cgen@sourceware.org 164 165The current CGEN maintainers are: 166 167 Doug Evans, Frank Eigler 168 169 --------- Write After Approval --------- 170 171Individuals with "write after approval" have the ability to check in 172changes, but they must get approval for each change from someone in 173one of the above lists (blanket write or maintainers). 174 175[It's a huge list, folks. You know who you are. If you have the 176 *ability* to do binutils checkins, you're in this group. Just 177 remember to get approval before checking anything in.] 178 179 ------------- Obvious Fixes ------------- 180 181Fixes for obvious mistakes do not need approval, and can be checked in 182right away, but the patch should still be sent to the binutils list. 183The definition of obvious is a bit hazy, and if you are not sure, then 184you should seek approval first. Obvious fixes include fixes for 185spelling mistakes, blatantly incorrect code (where the correct code is 186also blatantly obvious), and so on. Obvious fixes should always be 187small, the larger they are, the more likely it is that they contain 188some un-obvious side effect or consequence. 189 190 --------- Branch Checkins --------- 191 192If a patch is approved for check in to the mainline sources, it can 193also be checked into the current release branch. Normally however 194only bug fixes should be applied to the branch. New features, new 195ports, etc, should be restricted to the mainline. (Otherwise the 196burden of maintaining the branch in sync with the mainline becomes too 197great). If you are uncertain as to whether a patch is appropriate for 198the branch, ask the branch maintainer. This is: 199 200 Tristan Gingold <gingold@adacore.com> 201 202 -------- Testsuites --------------- 203 204In general patches to any of the binutils testsuites should be 205considered generic and sent to the binutils mailing list for 206approval. Patches to target specific tests are the responsibility the 207relevent port maintainer(s), and can be approved/checked in by them. 208Other testsuite patches need the approval of a blanket-write-priveleges 209person. 210 211 -------- Configure patches ---------- 212 213Patches to the top level configure files (config.sub & config.guess) 214are not the domain of the binutils project and they cannot be approved 215by the binutils group. Instead they should be submitted to the config 216maintainer at: 217 218 config-patches@gnu.org 219 220 --------- Creating Branches --------- 221 222Anyone with at least write-after-approval access may create a branch 223to use for their own development purposes. In keeping with FSF 224policies, all patches applied to such a branch must come from people 225with appropriate copyright assignments on file. All legal 226requirements that would apply to any other contribution apply equally 227to contributions on a branch. 228 229Before creating the branch, you should select a name for the branch of 230the form: 231 232 binutils-<org>-<name> 233 234where "org" is the initials of your organization, or your own initials 235if you are acting as an individual. For example, for a branch created 236by The GNUDist Company, "tgc" would be an appropriate choice for 237"org". It's up to each organization to select an appropriate choice 238for "name"; some organizations may use more structure than others, so 239"name" may contain additional hyphens. 240 241Suppose that The GNUDist Company was creating a branch to develop a 242port of Binutils to the FullMonty processor. Then, an appropriate 243choice of branch name would be: 244 245 binutils-tgc-fm 246 247A date stamp is not required as part of the name field, but some 248organizations like to have one. If you do include the date, you 249should follow these rules: 250 2511. The date should be the date that the branch was created. 252 2532. The date should be numerical and in the form YYYYMMDD. 254 255For example: 256 257 binutils-tgc-fm_20050101 258 259would be appropriate if the branch was created on January 1st, 2005. 260 261Having selected the branch name, create the branch as follows: 262 2631. Check out binutils, so that you have a git checkout corresponding 264 to the initial state of your branch. 265 2662. Create a tag: 267 268 git tag binutils-<org>-<name>-branchpoint 269 270 That tag will allow you, and others, to easily determine what's 271 changed on the branch relative to the initial state. 272 2733. Create and push the branch: 274 275 git checkout -b binutils-<org>-<name>-branch 276 git push origin HEAD 277 2784. Document the branch: 279 280 Add a description of the branch to binutils/BRANCHES, and check 281 that file in. All branch descriptions should be added to the 282 HEAD revision of the file; it doesn't help to modify 283 binutils/BRANCHES on a branch! 284 285Please do not commit any patches to a branch you did not create 286without the explicit permission of the person who created the branch. 287 288Copyright (C) 2012-2016 Free Software Foundation, Inc. 289 290Copying and distribution of this file, with or without modification, 291are permitted in any medium without royalty provided the copyright 292notice and this notice are preserved. 293