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