177298Sobrien ========= Binutils Maintainers ========= 277298Sobrien 377298SobrienThis is the list of individuals responsible for maintenance and update 489857Sobrienof the GNU Binary Utilities project. This includes the linker (ld), 589857Sobrienthe assembler (gas), the profiler (gprof), a whole suite of other 689857Sobrienprograms (binutils) and the libraries that they use (bfd and 789857Sobrienopcodes). This project shares a common set of header files with the 8218822SdimGCC and GDB projects (include), so maintainership of those files is 989857Sobrienshared amoungst the projects. 1077298Sobrien 1189857SobrienThe home page for binutils is: 1278828Sobrien 1389857Sobrien http://www.gnu.org/software/binutils/binutils.html 1489857Sobrien 1589857Sobrienand patches should be sent to: 1689857Sobrien 17218822Sdim binutils@sourceware.org 18218822Sdim 1989857Sobrienwith "[Patch]" as part of the subject line. Note - patches to the 20130561Sobrientop level config.guess and config.sub scripts should be sent to: 2189857Sobrien 2289857Sobrien config-patches@gnu.org 2389857Sobrien 24130561Sobrienand not to the binutils lists. Patches to the other top level 25218822Sdimconfigure files (configure, configure.in, config-ml.in) should 26218822Sdimbe sent to the binutils lists, and copied to the gcc and gdb 27130561Sobrienlists as well (gcc-patches@gcc.gnu.org and 28218822Sdimgdb-patches@sourceware.org). 2989857Sobrien 3077298Sobrien --------- Blanket Write Privs --------- 3177298Sobrien 3289857SobrienThe following people have permission to check patches into the 3389857Sobrienrepository without obtaining approval first: 34218822Sdim 3589857Sobrien Nick Clifton <nickc@redhat.com> (head maintainer) 3689857Sobrien Richard Henderson <rth@redhat.com> 37218822Sdim Ian Lance Taylor <ian@airs.com> 3889857Sobrien Jeff Law <law@redhat.com> 39130561Sobrien Jim Wilson <wilson@specifixinc.com> 4089857Sobrien DJ Delorie <dj@redhat.com> 4189857Sobrien Alan Modra <amodra@bigpond.net.au> 42130561Sobrien Michael Meissner <gnu@the-meissners.org> 43218822Sdim Daniel Jacobowitz <dan@debian.org> 4477298Sobrien 4589857Sobrien --------- Maintainers --------- 4677298Sobrien 4789857SobrienMaintainers are individuals who are responsible for, and have 4889857Sobrienpermission to check in changes in, certain subsets of the code. Note 4989857Sobrienthat maintainers still need approval to check in changes outside of 5089857Sobrienthe immediate domain that they maintain. 5177298Sobrien 5277298SobrienIf there is no maintainer for a given domain then the responsibility 5389857Sobrienfalls to the head maintainer (above). If there are several 5489857Sobrienmaintainers for a given domain then responsibility falls to the first 5589857Sobrienmaintainer. The first maintainer is free to devolve that 5689857Sobrienresponsibility among the other maintainers. 5777298Sobrien 58130561Sobrien ALPHA Richard Henderson <rth@redhat.com> 5989857Sobrien ARM Nick Clifton <nickc@redhat.com> 6089857Sobrien ARM Richard Earnshaw <rearnsha@arm.com> 61218822Sdim ARM Paul Brook <paul@codesourcery.com> 62218822Sdim ARM (Symbian) Mark Mitchell <mark@codesourcery.com> 6389857Sobrien AVR Denis Chertykov <denisc@overta.ru> 64104834Sobrien AVR Marek Michalkiewicz <marekm@amelek.gda.pl> 65218822Sdim BFIN Jie Zhang <jie.zhang@analog.com> 66218822Sdim BFIN Bernd Schmidt <bernd.schmidt@analog.com> 67130561Sobrien BUILD SYSTEM Ben Elliston <bje@gnu.org> 68130561Sobrien BUILD SYSTEM Daniel Jacobowitz <dan@debian.org> 6989857Sobrien CRIS Hans-Peter Nilsson <hp@axis.com> 70218822Sdim CRX Tomer Levi <Tomer.Levi@nsc.com> 71218822Sdim DLX Nikolaos Kavvadias <nkavv@physics.auth.gr> 7289857Sobrien DWARF2 Jason Merrill <jason@redhat.com> 73104834Sobrien FR30 Dave Brolley <brolley@redhat.com> 74104834Sobrien FRV Dave Brolley <brolley@redhat.com> 75218822Sdim FRV Alexandre Oliva <aoliva@redhat.com> 76218822Sdim H8300 Anil Paranjpe <anilp1@kpitcummins.com> 77130561Sobrien HPPA Dave Anglin <dave.anglin@nrc.ca> 7889857Sobrien HPPA elf32 Alan Modra <amodra@bigpond.net.au> 79130561Sobrien HPPA elf64 Jeff Law <law@redhat.com> [Basic maintainance only] 80130561Sobrien IA-64 Jim Wilson <wilson@specifixinc.com> 81130561Sobrien IQ2000 Stan Cox <scox@redhat.com> 82130561Sobrien i860 Jason Eckhardt <jle@rice.edu> 8389857Sobrien ix86 Alan Modra <amodra@bigpond.net.au> 84130561Sobrien ix86 PE Christopher Faylor <cgf@redhat.com> 85130561Sobrien ix86 COFF DJ Delorie <dj@redhat.com> 86218822Sdim ix86 H.J. Lu <hjl@gnu.org> 87218822Sdim ix86 INTEL MODE Jan Beulich <jbeulich@novell.com> 88104834Sobrien M68HC11 M68HC12 Stephane Carrez <stcarrez@nerim.fr> 89130561Sobrien M68k Ben Elliston <bje@gnu.org> 90218822Sdim M88k Mark Kettenis <kettenis@gnu.org> 91218822Sdim MAXQ Inderpreet Singh <inderpreetb@noida.hcltech.com> 92218822Sdim MEP Dave Brolley <brolley@redhat.com> 93218822Sdim MIPS Eric Christopher <echristo@apple.com> 94218822Sdim MIPS Thiemo Seufer <ths@networkno.de> 95104834Sobrien MMIX Hans-Peter Nilsson <hp@bitrange.com> 96218822Sdim MN10300 Eric Christopher <echristo@apple.com> 9791041Sobrien MN10300 Alexandre Oliva <aoliva@redhat.com> 98218822Sdim MSP430 Dmitry Diky <diwil@spec.ru> 99218822Sdim NetBSD support Matt Thomas <matt@netbsd.org> 100130561Sobrien PPC Geoff Keating <geoffk@geoffk.org> 101218822Sdim PPC Alan Modra <amodra@bigpond.net.au> 102130561Sobrien PPC vector ext Aldy Hernandez <aldyh@redhat.com> 10389857Sobrien s390, s390x Martin Schwidefsky <schwidefsky@de.ibm.com> 104218822Sdim SCORE Mei Ligang <ligang@sunnorth.com.cn> 10591041Sobrien SH Alexandre Oliva <aoliva@redhat.com> 106130561Sobrien SH Kaz Kojima <kkojima@rr.iij4u.or.jp> 10789857Sobrien SPARC Jakub Jelinek <jakub@redhat.com> 108130561Sobrien TESTSUITES Ben Elliston <bje@gnu.org> 109218822Sdim TIC4X Svein Seldal <svein@dev.seldal.com> 11089857Sobrien TIC54X Timothy Wall <twall@alum.mit.edu> 111218822Sdim VAX Matt Thomas <matt@netbsd.org> 112218822Sdim VAX Jan-Benedict Glaw <jbglaw@lug-owl.de> 113104834Sobrien x86_64 Jan Hubicka <jh@suse.cz> 114104834Sobrien x86_64 Andreas Jaeger <aj@suse.de> 115218822Sdim x86_64 H.J. Lu <hjl@gnu.org> 116130561Sobrien Xtensa Bob Wilson <bob.wilson@acm.org> 117218822Sdim z80 Arnold Metselaar <arnold.metselaar@planet.nl> 11899461Sobrien z8k Christian Groessler <chris@groessler.org> 11977298Sobrien 12099461Sobrien 12189857Sobrien --------- CGEN Maintainers ------------- 12277298Sobrien 12377298SobrienCGEN is a tool for building, amongst other things, assemblers, 12489857Sobriendisassemblers and simulators from a single description of a CPU. 12589857SobrienIt creates files in several of the binutils directories, but it 12689857Sobrienis mentioned here since there is a single group that maintains 127218822SdimCGEN and the files that it creates. 12877298Sobrien 12977298SobrienIf you have CGEN related problems you can send email to; 13077298Sobrien 131218822Sdim cgen@sourceware.org 13277298Sobrien 13377298SobrienThe current CGEN maintainers are: 13477298Sobrien 135218822Sdim Doug Evans, Frank Eigler 13677298Sobrien 13789857Sobrien --------- Write After Approval --------- 13877298Sobrien 13977298SobrienIndividuals with "write after approval" have the ability to check in 14077298Sobrienchanges, but they must get approval for each change from someone in 14177298Sobrienone of the above lists (blanket write or maintainers). 14277298Sobrien 14377298Sobrien[It's a huge list, folks. You know who you are. If you have the 14489857Sobrien *ability* to do binutils checkins, you're in this group. Just 14589857Sobrien remember to get approval before checking anything in.] 14678828Sobrien 14789857Sobrien ------------- Obvious Fixes ------------- 14878828Sobrien 14978828SobrienFixes for obvious mistakes do not need approval, and can be checked in 15078828Sobrienright away, but the patch should still be sent to the binutils list. 15178828SobrienThe definition of obvious is a bit hazy, and if you are not sure, then 15278828Sobrienyou should seek approval first. Obvious fixes include fixes for 15378828Sobrienspelling mistakes, blatantly incorrect code (where the correct code is 15478828Sobrienalso blatantly obvious), and so on. Obvious fixes should always be 15578828Sobriensmall, the larger they are, the more likely it is that they contain 15678828Sobriensome un-obvious side effect or consequence. 15789857Sobrien 15889857Sobrien --------- Branch Checkins --------- 15989857Sobrien 16089857SobrienIf a patch is approved for check in to the mainline sources, it can 16189857Sobrienalso be checked into the current release branch. Normally however 16289857Sobrienonly bug fixes should be applied to the branch. New features, new 16389857Sobrienports, etc, should be restricted to the mainline. (Otherwise the 164218822Sdimburden of maintaining the branch in sync with the mainline becomes too 16589857Sobriengreat). If you are uncertain as to whether a patch is appropriate for 16689857Sobrienthe branch, ask the branch maintainer. This is: 16789857Sobrien 16891041Sobrien Daniel Jacobowitz <dan@debian.org> 169130561Sobrien 170130561Sobrien -------- Testsuites --------------- 171130561Sobrien 172130561SobrienIn general patches to any of the binutils testsuites should be 173130561Sobrienconsidered generic and sent to the binutils mailing list for 174130561Sobrienapproval. Patches to target specific tests are the responsibility the 175130561Sobrienrelevent port maintainer(s), and can be approved/checked in by them. 176130561SobrienOther testsuite patches need the approval of a blanket-write-priveleges 177130561Sobrienperson. 178130561Sobrien 179130561Sobrien -------- Configure patches ---------- 180130561Sobrien 181130561SobrienPatches to the top level configure files (config.sub & config.guess) 182130561Sobrienare not the domain of the binutils project and they cannot be approved 183130561Sobrienby the binutils group. Instead they should be submitted to the config 184130561Sobrienmaintainer at: 185130561Sobrien 186130561Sobrien config-patches@gnu.org 187218822Sdim 188218822Sdim --------- Creating Branches --------- 189218822Sdim 190218822SdimAnyone with at least write-after-approval access may create a branch 191218822Sdimto use for their own development purposes. In keeping with FSF 192218822Sdimpolicies, all patches applied to such a branch must come from people 193218822Sdimwith appropriate copyright assignments on file. All legal 194218822Sdimrequirements that would apply to any other contribution apply equally 195218822Sdimto contributions on a branch. 196218822Sdim 197218822SdimBefore creating the branch, you should select a name for the branch of 198218822Sdimthe form: 199218822Sdim 200218822Sdim binutils-<org>-<name> 201218822Sdim 202218822Sdimwhere "org" is the initials of your organization, or your own initials 203218822Sdimif you are acting as an individual. For example, for a branch created 204218822Sdimby The GNUDist Company, "tgc" would be an appropriate choice for 205218822Sdim"org". It's up to each organization to select an appropriate choice 206218822Sdimfor "name"; some organizations may use more structure than others, so 207218822Sdim"name" may contain additional hyphens. 208218822Sdim 209218822SdimSuppose that The GNUDist Company was creating a branch to develop a 210218822Sdimport of Binutils to the FullMonty processor. Then, an appropriate 211218822Sdimchoice of branch name would be: 212218822Sdim 213218822Sdim binutils-tgc-fm 214218822Sdim 215218822SdimA data stamp is not required as part of the name field, but some 216218822Sdimorganizations like to have one. If you do include the date, you 217218822Sdimshould follow these rules: 218218822Sdim 219218822Sdim1. The date should be the date that the branch was created. 220218822Sdim 221218822Sdim2. The date should be numerical and in the form YYYYMMDD. 222218822Sdim 223218822SdimFor example: 224218822Sdim 225218822Sdim binutils-tgc-fm_20050101 226218822Sdim 227218822Sdimwould be appropriate if the branch was created on January 1st, 2005. 228218822Sdim 229218822SdimHaving selected the branch name, create the branch as follows: 230218822Sdim 231218822Sdim1. Check out binutils, so that you have a CVS checkout corresponding 232218822Sdim to the initial state of your branch. 233218822Sdim 234218822Sdim2. Create a tag: 235218822Sdim 236218822Sdim cvs tag binutils-<org>-<name>-branchpoint 237218822Sdim 238218822Sdim That tag will allow you, and others, to easily determine what's 239218822Sdim changed on the branch relative to the initial state. 240218822Sdim 241218822Sdim3. Create the branch: 242218822Sdim 243218822Sdim cvs rtag -b -r binutils-<org>-<name>-branchpoint \ 244218822Sdim binutils-<org>-<name>-branch 245218822Sdim 246218822Sdim4. Document the branch: 247218822Sdim 248218822Sdim Add a description of the branch to binutils/BRANCHES, and check 249218822Sdim that file in. All branch descriptions should be added to the 250218822Sdim HEAD revision of the file; it doesn't help to modify 251218822Sdim binutils/BRANCHES on a branch! 252218822Sdim 253218822SdimPlease do not commit any patches to a branch you did not create 254218822Sdimwithout the explicit permission of the person who created the branch. 255