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