| ========= 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 amongst 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.ac, 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). |
| |
| Patches to the libiberty sources should be sent to |
| gcc-patches@gcc.gnu.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) |
| 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> |
| Richard Sandiford <rdsandiford@googlemail.com> |
| Jan Beulich <jbeulich@suse.com> |
| |
| GDB global maintainers also have permission to commit and approve |
| patches to the top level files and to those parts of bfd files |
| primarily used by GDB. |
| |
| --------- 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. |
| |
| AARCH64 Richard Earnshaw <rearnsha@arm.com> |
| AARCH64 Marcus Shawcroft <marcus.shawcroft@arm.com> |
| ARC Claudiu Zissulescu <claziss@synopsys.com> |
| ARM Nick Clifton <nickc@redhat.com> |
| ARM Richard Earnshaw <rearnsha@arm.com> |
| ARM Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> |
| AVR Denis Chertykov <chertykov@gmail.com> |
| AVR Marek Michalkiewicz <marekm@amelek.gda.pl> |
| BFIN Jie Zhang <jzhang918@gmail.com> |
| BFIN Mike Frysinger <vapier@gentoo.org> |
| BPF Jose E. Marchesi <jose.marchesi@oracle.com> |
| 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> |
| CTF Nick Alcock <nick.alcock@oracle.com> |
| C-SKY Lifang Xia <lifang_xia@linux.alibaba.com> |
| C-SKY Yunhai Shang <yunhai@linux.alibaba.com> |
| DLX Nikolaos Kavvadias <nkavv@physics.auth.gr> |
| DWARF2 Jason Merrill <jason@redhat.com> |
| DWARF2 Jakub Jelinek <jakub@redhat.com> |
| dwarf-mode.el Tom Tromey <tom@tromey.com> |
| EPIPHANY Joern Rennecke <joern.rennecke@embecosm.com> |
| FR30 Nick Clifton <nickc@redhat.com> |
| FRV Nick Clifton <nickc@redhat.com> |
| FRV Alexandre Oliva <aoliva@sourceware.org> |
| GOLD Ian Lance Taylor <iant@google.com> |
| GOLD Cary Coutant <ccoutant@gmail.com> |
| gprofng Vladimir Mezentsev <vladimir.mezentsev@oracle.com> |
| H8300 Prafulla Thakare <prafulla.thakare@kpitcummins.com> |
| HPPA Dave Anglin <dave.anglin@bell.net> |
| HPPA elf64 Jeff Law <law@redhat.com> [Basic maintainance only] |
| IA-64 Jim Wilson <wilson@tuliptree.org> |
| IQ2000 Stan Cox <scox@redhat.com> |
| ix86 H.J. Lu <hjl.tools@gmail.com> |
| ix86 COFF DJ Delorie <dj@redhat.com> |
| ix86 PE/COFF Dave Korn <dave.korn.cygwin@gmail.com> |
| ix86 INTEL MODE Jan Beulich <jbeulich@suse.com> |
| KVX Paul Iannetta <piannetta@kalrayinc.com> |
| libsframe Indu Bhagat <indu.bhagat@oracle.com> |
| LM32 Jon Beniston <jon@beniston.com> |
| LoongArch Chenghua Xu <xuchenghua@loongson.cn> |
| LoongArch Zhensong Liu <liuzhensong@loongson.cn> |
| M32R Doug Evans <dje@sebabeach.org> |
| M68HC11 M68HC12 Stephane Carrez <Stephane.Carrez@gmail.com> |
| M68HC11 M68HC12 Sean Keys <skeys@ipdatasys.com> |
| MACH-O Tristan Gingold <tgingold@free.fr> |
| MAXQ Inderpreet Singh <inderpreetb@noida.hcltech.com> |
| MEP Nick Clifton <nickc@redhat.com> |
| METAG Markos Chandras <markos.chandras@imgtec.com> |
| MICROBLAZE Michael Eager <eager@eagercon.com> |
| MIPS Chenghua Xu <paul.hua.gm@gmail.com> |
| MIPS I-IV Maciej W. Rozycki <macro@orcam.me.uk> |
| MMIX Hans-Peter Nilsson <hp@bitrange.com> |
| MN10300 Alexandre Oliva <aoliva@sourceware.org> |
| Moxie Anthony Green <green@moxielogic.com> |
| NDS32 Kuan-Lin Chen <kuanlinchentw@gmail.com> |
| NDS32 Wei-Cheng Wang <cole945@gmail.com> |
| NetBSD support Matt Thomas <matt@netbsd.org> |
| Nios II Sandra Loosemore <sloosemore@baylibre.com> |
| Nios II Andrew Jenner <andrew@codesourcery.com> |
| OR1K Christian Svensson <blue@cmd.nu> |
| OR1K Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> |
| OR1K Stafford Horne <shorne@gmail.com> |
| PPC Peter Bergner <bergner@vnet.ibm.com> |
| PPC vector ext Aldy Hernandez <aldyh@redhat.com> |
| RISC-V Palmer Dabbelt <palmer@dabbelt.com> |
| RISC-V Andrew Waterman <andrew@sifive.com> |
| RISC-V Jim Wilson <jim.wilson.gcc@gmail.com> |
| RISC-V Nelson Chu <nelson@rivosinc.com> |
| RX Nick Clifton <nickc@redhat.com> |
| S12Z John Darrington <john@darrington.wattle.id.au> |
| s390, s390x Andreas Krebbel <krebbel@linux.ibm.com> |
| SH Alexandre Oliva <aoliva@sourceware.org> |
| SPARC David S. Miller <davem@davemloft.net> |
| SPARC Jose E. Marchesi <jose.marchesi@oracle.com> |
| SPU Alan Modra <amodra@gmail.com> |
| TIC54X Timothy Wall <twall@alum.mit.edu> |
| TIC6X Joseph Myers <josmyers@redhat.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> |
| Visium Eric Botcazou <ebotcazou@libertysurf.fr> |
| VMS Tristan Gingold <tgingold@free.fr> |
| x86_64 Jan Beulich <jbeulich@suse.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 Max Filippov <jcmvbkbc@gmail.com> |
| Xtensa Sterling Augustine <augustine.sterling@gmail.com> |
| z8k Christian Groessler <chris@groessler.org> |
| |
| --------- Past Maintainers ------------- |
| |
| These folks have acted as maintainers in the past, but have now |
| moved on to other things. Our thanks for all their hard work |
| goes with them. |
| |
| Paul Brook |
| Eric Christopher |
| Jason Eckhardt |
| Geoff Keating |
| Mark Kettenis |
| Mei Ligang |
| Arnold Metselaar |
| Mark Mitchell |
| Bernd Schmidt |
| Svein Seldal |
| Martin Schwidefsky |
| |
| --------- 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. |
| |
| Obvious fixes should not be "legally significant", as defined here: |
| |
| https://www.gnu.org/prep/maintain/maintain.html#Legally-Significant |
| |
| -------- Patches and Copyright --------- |
| |
| If a patch is non-obvious, its copyright must be considered. There |
| are two ways to handle this. The first is to assign the copyright |
| of the FSF. This ensures that if problems with the authorship of the |
| patch arise, the FSF will be able to deal with them. |
| |
| The list of already assigned copyrights can be obtained from |
| fencepost.gnu.org in the file: /gd/gnuorg/copyright.list. |
| |
| New copyright assignments can be obtained by completing one of the |
| forms found here and sending it off to the FSF: |
| |
| https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=tree;f=doc/Copyright |
| |
| The alternative is to sign off the contribution by agreeing to the |
| Developer's Certificate of Origin (version 1.1 or later) and adding a |
| line to the end of the contribution that looks something like this: |
| |
| Signed-off-by: Random J Developer <random@developer.example.org> |
| |
| The details of the Developer's Certificate or Origin can be found here: |
| |
| https://developercertificate.org/ |
| |
| --------- 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: |
| |
| (cf global maintainers) |
| |
| -------- 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 |
| relevant 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 git checkout corresponding |
| to the initial state of your branch. |
| |
| 2. Create a tag: |
| |
| git 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 and push the branch: |
| |
| git checkout -b binutils-<org>-<name>-branch |
| git push origin HEAD |
| |
| 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-2024 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. |
