MAINTAINERS revision 1.1
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 (a] 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 (a] gnu.org 23 24 and not to the binutils lists. Patches to the other top level 25 configure files (configure, configure.in, config-ml.in) should 26 be sent to the binutils lists, and copied to the gcc and gdb 27 lists as well (gcc-patches (a] gcc.gnu.org and 28 gdb-patches (a] sourceware.org). 29 30 --------- Blanket Write Privs --------- 31 32 The following people have permission to check patches into the 33 repository without obtaining approval first: 34 35 Nick Clifton <nickc (a] redhat.com> (head maintainer) 36 Richard Henderson <rth (a] redhat.com> 37 Ian Lance Taylor <ian (a] airs.com> 38 Jeff Law <law (a] redhat.com> 39 Jim Wilson <wilson (a] tuliptree.org> 40 DJ Delorie <dj (a] redhat.com> 41 Alan Modra <amodra (a] gmail.com> 42 Michael Meissner <gnu (a] the-meissners.org> 43 Daniel Jacobowitz <drow (a] false.org> 44 Richard Sandiford <rdsandiford (a] googlemail.com> 45 46 --------- Maintainers --------- 47 48 Maintainers are individuals who are responsible for, and have 49 permission to check in changes in, certain subsets of the code. Note 50 that maintainers still need approval to check in changes outside of 51 the immediate domain that they maintain. 52 53 If there is no maintainer for a given domain then the responsibility 54 falls to the head maintainer (above). If there are several 55 maintainers for a given domain then responsibility falls to the first 56 maintainer. The first maintainer is free to devolve that 57 responsibility among the other maintainers. 58 59 ALPHA Richard Henderson <rth (a] redhat.com> 60 AARCH64 Richard Earnshaw <rearnsha (a] arm.com> 61 ARM Nick Clifton <nickc (a] redhat.com> 62 ARM Richard Earnshaw <rearnsha (a] arm.com> 63 ARM Paul Brook <paul (a] codesourcery.com> 64 ARM (Symbian) Mark Mitchell <mark (a] codesourcery.com> 65 AVR Denis Chertykov <denisc (a] overta.ru> 66 AVR Marek Michalkiewicz <marekm (a] amelek.gda.pl> 67 BFIN Jie Zhang <jzhang918 (a] gmail.com> 68 BFIN Bernd Schmidt <bernd.schmidt (a] analog.com> 69 BFIN Mike Frysinger <michael.frysinger (a] analog.com> 70 BUILD SYSTEM Daniel Jacobowitz <drow (a] false.org> 71 CR16 M R Swami Reddy <MR.Swami.Reddy (a] nsc.com> 72 CRIS Hans-Peter Nilsson <hp (a] axis.com> 73 CRX M R Swami Reddy <MR.Swami.Reddy (a] nsc.com> 74 DLX Nikolaos Kavvadias <nkavv (a] physics.auth.gr> 75 DWARF2 Jason Merrill <jason (a] redhat.com> 76 DWARF2 Jakub Jelinek <jakub (a] redhat.com> 77 EPIPHANY Joern Rennecke <joern.rennecke (a] embecosm.com> 78 FR30 Dave Brolley <brolley (a] redhat.com> 79 FRV Dave Brolley <brolley (a] redhat.com> 80 FRV Alexandre Oliva <aoliva (a] redhat.com> 81 H8300 Prafulla Thakare <prafulla.thakare (a] kpitcummins.com> 82 HPPA Dave Anglin <dave.anglin (a] nrc.ca> 83 HPPA elf32 Alan Modra <amodra (a] gmail.com> 84 HPPA elf64 Jeff Law <law (a] redhat.com> [Basic maintainance only] 85 IA-64 Jim Wilson <wilson (a] tuliptree.org> 86 IQ2000 Stan Cox <scox (a] redhat.com> 87 i860 Jason Eckhardt <jle (a] rice.edu> 88 ix86 H.J. Lu <hjl.tools (a] gmail.com> 89 ix86 PE Christopher Faylor <me+binutils (a] cgf.cx> 90 ix86 COFF DJ Delorie <dj (a] redhat.com> 91 ix86 PE/COFF Dave Korn <dave.korn.cygwin (a] gmail.com> 92 ix86 INTEL MODE Jan Beulich <jbeulich (a] novell.com> 93 LM32 Jon Beniston <jon (a] beniston.com> 94 M32R Doug Evans <dje (a] sebabeach.org> 95 M68HC11 M68HC12 Stephane Carrez <stcarrez (a] nerim.fr> 96 M68HC11 M68HC12 Sean Keys <skeys (a] ipdatasys.com> 97 M88k Mark Kettenis <kettenis (a] gnu.org> 98 MACH-O Tristan Gingold <gingold (a] adacore.com> 99 MAXQ Inderpreet Singh <inderpreetb (a] noida.hcltech.com> 100 MEP Dave Brolley <brolley (a] redhat.com> 101 MICROBLAZE Michael Eager <eager (a] eagercon.com> 102 MIPS Eric Christopher <echristo (a] apple.com> 103 MMIX Hans-Peter Nilsson <hp (a] bitrange.com> 104 MN10300 Eric Christopher <echristo (a] apple.com> 105 MN10300 Alexandre Oliva <aoliva (a] redhat.com> 106 Moxie Anthony Green <green (a] moxielogic.com> 107 MSP430 Dmitry Diky <diwil (a] spec.ru> 108 NetBSD support Matt Thomas <matt (a] netbsd.org> 109 PPC Geoff Keating <geoffk (a] geoffk.org> 110 PPC Alan Modra <amodra (a] gmail.com> 111 PPC vector ext Aldy Hernandez <aldyh (a] redhat.com> 112 RL78 DJ Delorie <dj (a] redhat.com> 113 RX DJ Delorie <dj (a] redhat.com> 114 RX Nick Clifton <nickc (a] redhat.com> 115 s390, s390x Martin Schwidefsky <schwidefsky (a] de.ibm.com> 116 SCORE Mei Ligang <ligang (a] sunnorth.com.cn> 117 SH Alexandre Oliva <aoliva (a] redhat.com> 118 SH Kaz Kojima <kkojima (a] rr.iij4u.or.jp> 119 SPARC David S. Miller <davem (a] davemloft.net> 120 SPU Alan Modra <amodra (a] gmail.com> 121 TIC4X Svein Seldal <svein (a] dev.seldal.com> 122 TIC54X Timothy Wall <twall (a] alum.mit.edu> 123 TIC6X Joseph Myers <joseph (a] codesourcery.com> 124 TILE-Gx Walter Lee <walt (a] tilera.com> 125 TILEPro Walter Lee <walt (a] tilera.com> 126 VAX Matt Thomas <matt (a] netbsd.org> 127 VAX Jan-Benedict Glaw <jbglaw (a] lug-owl.de> 128 VMS Tristan Gingold <gingold (a] adacore.com> 129 x86_64 Jan Hubicka <jh (a] suse.cz> 130 x86_64 Andreas Jaeger <aj (a] suse.de> 131 x86_64 H.J. Lu <hjl.tools (a] gmail.com> 132 XCOFF Richard Sandiford <r.sandiford (a] uk.ibm.com> 133 XGATE Sean Keys <skeys (a] ipdatasys.com> 134 Xtensa Sterling Augustine <augustine.sterling (a] gmail.com> 135 z80 Arnold Metselaar <arnold.metselaar (a] planet.nl> 136 z8k Christian Groessler <chris (a] groessler.org> 137 138 139 --------- CGEN Maintainers ------------- 140 141 CGEN is a tool for building, amongst other things, assemblers, 142 disassemblers and simulators from a single description of a CPU. 143 It creates files in several of the binutils directories, but it 144 is mentioned here since there is a single group that maintains 145 CGEN and the files that it creates. 146 147 If you have CGEN related problems you can send email to; 148 149 cgen (a] sourceware.org 150 151 The current CGEN maintainers are: 152 153 Doug Evans, Frank Eigler 154 155 --------- Write After Approval --------- 156 157 Individuals with "write after approval" have the ability to check in 158 changes, but they must get approval for each change from someone in 159 one of the above lists (blanket write or maintainers). 160 161 [It's a huge list, folks. You know who you are. If you have the 162 *ability* to do binutils checkins, you're in this group. Just 163 remember to get approval before checking anything in.] 164 165 ------------- Obvious Fixes ------------- 166 167 Fixes for obvious mistakes do not need approval, and can be checked in 168 right away, but the patch should still be sent to the binutils list. 169 The definition of obvious is a bit hazy, and if you are not sure, then 170 you should seek approval first. Obvious fixes include fixes for 171 spelling mistakes, blatantly incorrect code (where the correct code is 172 also blatantly obvious), and so on. Obvious fixes should always be 173 small, the larger they are, the more likely it is that they contain 174 some un-obvious side effect or consequence. 175 176 --------- Branch Checkins --------- 177 178 If a patch is approved for check in to the mainline sources, it can 179 also be checked into the current release branch. Normally however 180 only bug fixes should be applied to the branch. New features, new 181 ports, etc, should be restricted to the mainline. (Otherwise the 182 burden of maintaining the branch in sync with the mainline becomes too 183 great). If you are uncertain as to whether a patch is appropriate for 184 the branch, ask the branch maintainer. This is: 185 186 Tristan Gingold <gingold (a] adacore.com> 187 188 -------- Testsuites --------------- 189 190 In general patches to any of the binutils testsuites should be 191 considered generic and sent to the binutils mailing list for 192 approval. Patches to target specific tests are the responsibility the 193 relevent port maintainer(s), and can be approved/checked in by them. 194 Other testsuite patches need the approval of a blanket-write-priveleges 195 person. 196 197 -------- Configure patches ---------- 198 199 Patches to the top level configure files (config.sub & config.guess) 200 are not the domain of the binutils project and they cannot be approved 201 by the binutils group. Instead they should be submitted to the config 202 maintainer at: 203 204 config-patches (a] gnu.org 205 206 --------- Creating Branches --------- 207 208 Anyone with at least write-after-approval access may create a branch 209 to use for their own development purposes. In keeping with FSF 210 policies, all patches applied to such a branch must come from people 211 with appropriate copyright assignments on file. All legal 212 requirements that would apply to any other contribution apply equally 213 to contributions on a branch. 214 215 Before creating the branch, you should select a name for the branch of 216 the form: 217 218 binutils-<org>-<name> 219 220 where "org" is the initials of your organization, or your own initials 221 if you are acting as an individual. For example, for a branch created 222 by The GNUDist Company, "tgc" would be an appropriate choice for 223 "org". It's up to each organization to select an appropriate choice 224 for "name"; some organizations may use more structure than others, so 225 "name" may contain additional hyphens. 226 227 Suppose that The GNUDist Company was creating a branch to develop a 228 port of Binutils to the FullMonty processor. Then, an appropriate 229 choice of branch name would be: 230 231 binutils-tgc-fm 232 233 A date stamp is not required as part of the name field, but some 234 organizations like to have one. If you do include the date, you 235 should follow these rules: 236 237 1. The date should be the date that the branch was created. 238 239 2. The date should be numerical and in the form YYYYMMDD. 240 241 For example: 242 243 binutils-tgc-fm_20050101 244 245 would be appropriate if the branch was created on January 1st, 2005. 246 247 Having selected the branch name, create the branch as follows: 248 249 1. Check out binutils, so that you have a CVS checkout corresponding 250 to the initial state of your branch. 251 252 2. Create a tag: 253 254 cvs tag binutils-<org>-<name>-branchpoint 255 256 That tag will allow you, and others, to easily determine what's 257 changed on the branch relative to the initial state. 258 259 3. Create the branch: 260 261 cvs rtag -b -r binutils-<org>-<name>-branchpoint \ 262 binutils-<org>-<name>-branch 263 264 4. Document the branch: 265 266 Add a description of the branch to binutils/BRANCHES, and check 267 that file in. All branch descriptions should be added to the 268 HEAD revision of the file; it doesn't help to modify 269 binutils/BRANCHES on a branch! 270 271 Please do not commit any patches to a branch you did not create 272 without the explicit permission of the person who created the branch. 273
Indexes created Fri Jun 26 00:24:39 UTC 2026