diff options
Diffstat (limited to 'binutils-2.24/binutils/MAINTAINERS')
| -rw-r--r-- | binutils-2.24/binutils/MAINTAINERS | 284 |
1 files changed, 0 insertions, 284 deletions
diff --git a/binutils-2.24/binutils/MAINTAINERS b/binutils-2.24/binutils/MAINTAINERS deleted file mode 100644 index 3ea36851..00000000 --- a/binutils-2.24/binutils/MAINTAINERS +++ /dev/null @@ -1,284 +0,0 @@ - ========= Binutils Maintainers ========= - -This is the list of individuals responsible for maintenance and update -of the GNU Binary Utilities project. This includes the linker (ld), -the assembler (gas), the profiler (gprof), a whole suite of other -programs (binutils) and the libraries that they use (bfd and -opcodes). This project shares a common set of header files with the -GCC and GDB projects (include), so maintainership of those files is -shared amoungst the projects. - -The home page for binutils is: - - http://www.gnu.org/software/binutils/binutils.html - -and patches should be sent to: - - binutils@sourceware.org - -with "[Patch]" as part of the subject line. Note - patches to the -top level config.guess and config.sub scripts should be sent to: - - config-patches@gnu.org - -and not to the binutils lists. Patches to the other top level -configure files (configure, configure.in, config-ml.in) should -be sent to the binutils lists, and copied to the gcc and gdb -lists as well (gcc-patches@gcc.gnu.org and -gdb-patches@sourceware.org). - - --------- Blanket Write Privs --------- - -The following people have permission to check patches into the -repository without obtaining approval first: - - Nick Clifton <nickc@redhat.com> (head maintainer) - Richard Henderson <rth@redhat.com> - Ian Lance Taylor <ian@airs.com> - Jeff Law <law@redhat.com> - Jim Wilson <wilson@tuliptree.org> - DJ Delorie <dj@redhat.com> - Alan Modra <amodra@gmail.com> - Michael Meissner <gnu@the-meissners.org> - Daniel Jacobowitz <drow@false.org> - Richard Sandiford <rdsandiford@googlemail.com> - - --------- Maintainers --------- - -Maintainers are individuals who are responsible for, and have -permission to check in changes in, certain subsets of the code. Note -that maintainers still need approval to check in changes outside of -the immediate domain that they maintain. - -If there is no maintainer for a given domain then the responsibility -falls to the head maintainer (above). If there are several -maintainers for a given domain then responsibility falls to the first -maintainer. The first maintainer is free to devolve that -responsibility among the other maintainers. - - ALPHA Richard Henderson <rth@redhat.com> - AARCH64 Richard Earnshaw <rearnsha@arm.com> - AARCH64 Marcus Shawcroft <marcus.shawcroft@arm.com> - ARM Nick Clifton <nickc@redhat.com> - ARM Richard Earnshaw <rearnsha@arm.com> - ARM Paul Brook <paul@codesourcery.com> - ARM (Symbian) Mark Mitchell <mark@codesourcery.com> - AVR Denis Chertykov <denisc@overta.ru> - AVR Marek Michalkiewicz <marekm@amelek.gda.pl> - BFIN Jie Zhang <jzhang918@gmail.com> - BFIN Bernd Schmidt <bernd.schmidt@analog.com> - BFIN Mike Frysinger <michael.frysinger@analog.com> - BUILD SYSTEM Daniel Jacobowitz <drow@false.org> - CR16 M R Swami Reddy <MR.Swami.Reddy@nsc.com> - CRIS Hans-Peter Nilsson <hp@axis.com> - CRX M R Swami Reddy <MR.Swami.Reddy@nsc.com> - DLX Nikolaos Kavvadias <nkavv@physics.auth.gr> - DWARF2 Jason Merrill <jason@redhat.com> - DWARF2 Jakub Jelinek <jakub@redhat.com> - EPIPHANY Joern Rennecke <joern.rennecke@embecosm.com> - FR30 Dave Brolley <brolley@redhat.com> - FRV Dave Brolley <brolley@redhat.com> - FRV Alexandre Oliva <aoliva@redhat.com> - GOLD Ian Lance Taylor <iant@google.com> - GOLD Cary Coutant <ccoutant@google.com> - H8300 Prafulla Thakare <prafulla.thakare@kpitcummins.com> - HPPA Dave Anglin <dave.anglin@nrc.ca> - HPPA elf32 Alan Modra <amodra@gmail.com> - HPPA elf64 Jeff Law <law@redhat.com> [Basic maintainance only] - IA-64 Jim Wilson <wilson@tuliptree.org> - IQ2000 Stan Cox <scox@redhat.com> - i860 Jason Eckhardt <jle@rice.edu> - ix86 H.J. Lu <hjl.tools@gmail.com> - ix86 PE Christopher Faylor <me+binutils@cgf.cx> - ix86 COFF DJ Delorie <dj@redhat.com> - ix86 PE/COFF Dave Korn <dave.korn.cygwin@gmail.com> - ix86 INTEL MODE Jan Beulich <jbeulich@novell.com> - LM32 Jon Beniston <jon@beniston.com> - M32R Doug Evans <dje@sebabeach.org> - M68HC11 M68HC12 Stephane Carrez <Stephane.Carrez@gmail.com> - M68HC11 M68HC12 Sean Keys <skeys@ipdatasys.com> - M88k Mark Kettenis <kettenis@gnu.org> - MACH-O Tristan Gingold <gingold@adacore.com> - MAXQ Inderpreet Singh <inderpreetb@noida.hcltech.com> - MEP Dave Brolley <brolley@redhat.com> - METAG Markos Chandras <markos.chandras@imgtec.com> - MICROBLAZE Michael Eager <eager@eagercon.com> - MIPS Eric Christopher <echristo@apple.com> - MMIX Hans-Peter Nilsson <hp@bitrange.com> - MN10300 Eric Christopher <echristo@apple.com> - MN10300 Alexandre Oliva <aoliva@redhat.com> - Moxie Anthony Green <green@moxielogic.com> - MSP430 Dmitry Diky <diwil@spec.ru> - NetBSD support Matt Thomas <matt@netbsd.org> - Nios II Sandra Loosemore <sandra@codesourcery.com> - Nios II Andrew Jenner <andrew@codesourcery.com> - PPC Geoff Keating <geoffk@geoffk.org> - PPC Alan Modra <amodra@gmail.com> - PPC vector ext Aldy Hernandez <aldyh@redhat.com> - RL78 DJ Delorie <dj@redhat.com> - RX DJ Delorie <dj@redhat.com> - RX Nick Clifton <nickc@redhat.com> - s390, s390x Martin Schwidefsky <schwidefsky@de.ibm.com> - SCORE Mei Ligang <ligang@sunnorth.com.cn> - SH Alexandre Oliva <aoliva@redhat.com> - SH Kaz Kojima <kkojima@rr.iij4u.or.jp> - SPARC David S. Miller <davem@davemloft.net> - SPU Alan Modra <amodra@gmail.com> - TIC4X Svein Seldal <svein@dev.seldal.com> - TIC54X Timothy Wall <twall@alum.mit.edu> - TIC6X Joseph Myers <joseph@codesourcery.com> - TILE-Gx Walter Lee <walt@tilera.com> - TILEPro Walter Lee <walt@tilera.com> - VAX Matt Thomas <matt@netbsd.org> - VAX Jan-Benedict Glaw <jbglaw@lug-owl.de> - VMS Tristan Gingold <gingold@adacore.com> - x86_64 Jan Hubicka <jh@suse.cz> - x86_64 Andreas Jaeger <aj@suse.de> - x86_64 H.J. Lu <hjl.tools@gmail.com> - XCOFF Richard Sandiford <r.sandiford@uk.ibm.com> - XGATE Sean Keys <skeys@ipdatasys.com> - Xtensa Sterling Augustine <augustine.sterling@gmail.com> - z80 Arnold Metselaar <arnold.metselaar@planet.nl> - z8k Christian Groessler <chris@groessler.org> - - - --------- CGEN Maintainers ------------- - -CGEN is a tool for building, amongst other things, assemblers, -disassemblers and simulators from a single description of a CPU. -It creates files in several of the binutils directories, but it -is mentioned here since there is a single group that maintains -CGEN and the files that it creates. - -If you have CGEN related problems you can send email to; - - cgen@sourceware.org - -The current CGEN maintainers are: - - Doug Evans, Frank Eigler - - --------- Write After Approval --------- - -Individuals with "write after approval" have the ability to check in -changes, but they must get approval for each change from someone in -one of the above lists (blanket write or maintainers). - -[It's a huge list, folks. You know who you are. If you have the - *ability* to do binutils checkins, you're in this group. Just - remember to get approval before checking anything in.] - - ------------- Obvious Fixes ------------- - -Fixes for obvious mistakes do not need approval, and can be checked in -right away, but the patch should still be sent to the binutils list. -The definition of obvious is a bit hazy, and if you are not sure, then -you should seek approval first. Obvious fixes include fixes for -spelling mistakes, blatantly incorrect code (where the correct code is -also blatantly obvious), and so on. Obvious fixes should always be -small, the larger they are, the more likely it is that they contain -some un-obvious side effect or consequence. - - --------- Branch Checkins --------- - -If a patch is approved for check in to the mainline sources, it can -also be checked into the current release branch. Normally however -only bug fixes should be applied to the branch. New features, new -ports, etc, should be restricted to the mainline. (Otherwise the -burden of maintaining the branch in sync with the mainline becomes too -great). If you are uncertain as to whether a patch is appropriate for -the branch, ask the branch maintainer. This is: - - Tristan Gingold <gingold@adacore.com> - - -------- Testsuites --------------- - -In general patches to any of the binutils testsuites should be -considered generic and sent to the binutils mailing list for -approval. Patches to target specific tests are the responsibility the -relevent port maintainer(s), and can be approved/checked in by them. -Other testsuite patches need the approval of a blanket-write-priveleges -person. - - -------- Configure patches ---------- - -Patches to the top level configure files (config.sub & config.guess) -are not the domain of the binutils project and they cannot be approved -by the binutils group. Instead they should be submitted to the config -maintainer at: - - config-patches@gnu.org - - --------- Creating Branches --------- - -Anyone with at least write-after-approval access may create a branch -to use for their own development purposes. In keeping with FSF -policies, all patches applied to such a branch must come from people -with appropriate copyright assignments on file. All legal -requirements that would apply to any other contribution apply equally -to contributions on a branch. - -Before creating the branch, you should select a name for the branch of -the form: - - binutils-<org>-<name> - -where "org" is the initials of your organization, or your own initials -if you are acting as an individual. For example, for a branch created -by The GNUDist Company, "tgc" would be an appropriate choice for -"org". It's up to each organization to select an appropriate choice -for "name"; some organizations may use more structure than others, so -"name" may contain additional hyphens. - -Suppose that The GNUDist Company was creating a branch to develop a -port of Binutils to the FullMonty processor. Then, an appropriate -choice of branch name would be: - - binutils-tgc-fm - -A date stamp is not required as part of the name field, but some -organizations like to have one. If you do include the date, you -should follow these rules: - -1. The date should be the date that the branch was created. - -2. The date should be numerical and in the form YYYYMMDD. - -For example: - - binutils-tgc-fm_20050101 - -would be appropriate if the branch was created on January 1st, 2005. - -Having selected the branch name, create the branch as follows: - -1. Check out binutils, so that you have a CVS checkout corresponding - to the initial state of your branch. - -2. Create a tag: - - cvs tag binutils-<org>-<name>-branchpoint - - That tag will allow you, and others, to easily determine what's - changed on the branch relative to the initial state. - -3. Create the branch: - - cvs rtag -b -r binutils-<org>-<name>-branchpoint \ - binutils-<org>-<name>-branch - -4. Document the branch: - - Add a description of the branch to binutils/BRANCHES, and check - that file in. All branch descriptions should be added to the - HEAD revision of the file; it doesn't help to modify - binutils/BRANCHES on a branch! - -Please do not commit any patches to a branch you did not create -without the explicit permission of the person who created the branch. - -Copyright (C) 2012 Free Software Foundation, Inc. - -Copying and distribution of this file, with or without modification, -are permitted in any medium without royalty provided the copyright -notice and this notice are preserved. |