OpenCores
URL https://opencores.org/ocsvn/open8_urisc/open8_urisc/trunk

Subversion Repositories open8_urisc

[/] [open8_urisc/] [trunk/] [gnu/] [binutils/] [binutils/] [MAINTAINERS] - Blame information for rev 160

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 15 khays
                ========= 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  (head maintainer)
36
  Richard Henderson 
37
  Ian Lance Taylor 
38
  Jeff Law 
39
  Jim Wilson 
40
  DJ Delorie 
41
  Alan Modra 
42
  Michael Meissner 
43
  Daniel Jacobowitz 
44
  Richard Sandiford 
45
 
46
      --------- Maintainers ---------
47
 
48
Maintainers are individuals who are responsible for, and have
49
permission to check in changes in, certain subsets of the code.  Note
50
that maintainers still need approval to check in changes outside of
51
the immediate domain that they maintain.
52
 
53
If there is no maintainer for a given domain then the responsibility
54
falls to the head maintainer (above).  If there are several
55
maintainers for a given domain then responsibility falls to the first
56
maintainer.  The first maintainer is free to devolve that
57
responsibility among the other maintainers.
58
 
59
  ALPHA            Richard Henderson 
60
  ARM              Nick Clifton 
61
  ARM              Richard Earnshaw 
62
  ARM              Paul Brook 
63
  ARM (Symbian)    Mark Mitchell 
64
  AVR              Denis Chertykov 
65
  AVR              Marek Michalkiewicz 
66
  BFIN             Jie Zhang 
67
  BFIN             Bernd Schmidt 
68
  BFIN             Mike Frysinger 
69
  BUILD SYSTEM     Daniel Jacobowitz 
70
  CR16             M R Swami Reddy 
71
  CRIS             Hans-Peter Nilsson 
72
  CRX              M R Swami Reddy 
73
  DLX              Nikolaos Kavvadias 
74
  DWARF2           Jason Merrill 
75
  DWARF2           Jakub Jelinek 
76
  FR30             Dave Brolley 
77
  FRV              Dave Brolley 
78
  FRV              Alexandre Oliva 
79
  H8300            Prafulla Thakare 
80
  HPPA             Dave Anglin 
81
  HPPA elf32       Alan Modra 
82
  HPPA elf64       Jeff Law  [Basic maintainance only]
83
  IA-64            Jim Wilson 
84
  IQ2000           Stan Cox 
85
  i860             Jason Eckhardt 
86
  ix86             H.J. Lu 
87
  ix86 PE          Christopher Faylor 
88
  ix86 COFF        DJ Delorie 
89
  ix86 PE/COFF     Dave Korn 
90
  ix86 INTEL MODE  Jan Beulich 
91
  LM32             Jon Beniston 
92
  M32R             Doug Evans 
93
  M68HC11 M68HC12  Stephane Carrez 
94
  M88k             Mark Kettenis 
95
  MACH-O           Tristan Gingold 
96
  MAXQ             Inderpreet Singh 
97
  MEP              Dave Brolley 
98
  MICROBLAZE       Michael Eager 
99
  MIPS             Eric Christopher 
100
  MMIX             Hans-Peter Nilsson 
101
  MN10300          Eric Christopher 
102
  MN10300          Alexandre Oliva 
103
  Moxie            Anthony Green 
104
  MSP430           Dmitry Diky 
105
  NetBSD support   Matt Thomas 
106
  Open8            Kirk Hays 
107
  PPC              Geoff Keating 
108
  PPC              Alan Modra 
109
  PPC vector ext   Aldy Hernandez 
110
  RX               DJ Delorie 
111
  RX               Nick Clifton 
112
  s390, s390x      Martin Schwidefsky 
113
  SCORE            Mei Ligang 
114
  SH               Alexandre Oliva 
115
  SH               Kaz Kojima 
116
  SPARC            Jakub Jelinek 
117
  SPU              Alan Modra 
118
  TIC4X            Svein Seldal 
119
  TIC54X           Timothy Wall 
120
  TIC6X            Joseph Myers 
121
  VAX              Matt Thomas 
122
  VAX              Jan-Benedict Glaw 
123
  VMS              Tristan Gingold 
124
  x86_64           Jan Hubicka 
125
  x86_64           Andreas Jaeger 
126
  x86_64           H.J. Lu 
127
  XCOFF            Richard Sandiford 
128
  Xtensa           Sterling Augustine 
129
  z80              Arnold Metselaar 
130
  z8k              Christian Groessler 
131
 
132
 
133
      --------- CGEN Maintainers -------------
134
 
135
CGEN is a tool for building, amongst other things, assemblers,
136
disassemblers and simulators from a single description of a CPU.
137
It creates files in several of the binutils directories, but it
138
is mentioned here since there is a single group that maintains
139
CGEN and the files that it creates.
140
 
141
If you have CGEN related problems you can send email to;
142
 
143
   cgen@sourceware.org
144
 
145
The current CGEN maintainers are:
146
 
147
  Doug Evans, Frank Eigler
148
 
149
     --------- Write After Approval ---------
150
 
151
Individuals with "write after approval" have the ability to check in
152
changes, but they must get approval for each change from someone in
153
one of the above lists (blanket write or maintainers).
154
 
155
[It's a huge list, folks.  You know who you are.  If you have the
156
 *ability* to do binutils checkins, you're in this group.  Just
157
 remember to get approval before checking anything in.]
158
 
159
     -------------  Obvious Fixes -------------
160
 
161
Fixes for obvious mistakes do not need approval, and can be checked in
162
right away, but the patch should still be sent to the binutils list.
163
The definition of obvious is a bit hazy, and if you are not sure, then
164
you should seek approval first.  Obvious fixes include fixes for
165
spelling mistakes, blatantly incorrect code (where the correct code is
166
also blatantly obvious), and so on.  Obvious fixes should always be
167
small, the larger they are, the more likely it is that they contain
168
some un-obvious side effect or consequence.
169
 
170
    --------- Branch Checkins ---------
171
 
172
If a patch is approved for check in to the mainline sources, it can
173
also be checked into the current release branch.  Normally however
174
only bug fixes should be applied to the branch.  New features, new
175
ports, etc, should be restricted to the mainline.  (Otherwise the
176
burden of maintaining the branch in sync with the mainline becomes too
177
great).  If you are uncertain as to whether a patch is appropriate for
178
the branch, ask the branch maintainer.  This is:
179
 
180
   Tristan Gingold  
181
 
182
    -------- Testsuites ---------------
183
 
184
In general patches to any of the binutils testsuites should be
185
considered generic and sent to the binutils mailing list for
186
approval.  Patches to target specific tests are the responsibility the
187
relevent port maintainer(s), and can be approved/checked in by them.
188
Other testsuite patches need the approval of a blanket-write-priveleges
189
person.
190
 
191
    -------- Configure patches ----------
192
 
193
Patches to the top level configure files (config.sub & config.guess)
194
are not the domain of the binutils project and they cannot be approved
195
by the binutils group.  Instead they should be submitted to the config
196
maintainer at:
197
 
198
        config-patches@gnu.org
199
 
200
    --------- Creating Branches ---------
201
 
202
Anyone with at least write-after-approval access may create a branch
203
to use for their own development purposes.  In keeping with FSF
204
policies, all patches applied to such a branch must come from people
205
with appropriate copyright assignments on file.  All legal
206
requirements that would apply to any other contribution apply equally
207
to contributions on a branch.
208
 
209
Before creating the branch, you should select a name for the branch of
210
the form:
211
 
212
  binutils--
213
 
214
where "org" is the initials of your organization, or your own initials
215
if you are acting as an individual.  For example, for a branch created
216
by The GNUDist Company, "tgc" would be an appropriate choice for
217
"org".  It's up to each organization to select an appropriate choice
218
for "name"; some organizations may use more structure than others, so
219
"name" may contain additional hyphens.
220
 
221
Suppose that The GNUDist Company was creating a branch to develop a
222
port of Binutils to the FullMonty processor.  Then, an appropriate
223
choice of branch name would be:
224
 
225
  binutils-tgc-fm
226
 
227
A date stamp is not required as part of the name field, but some
228
organizations like to have one.  If you do include the date, you
229
should follow these rules:
230
 
231
1. The date should be the date that the branch was created.
232
 
233
2. The date should be numerical and in the form YYYYMMDD.
234
 
235
For example:
236
 
237
  binutils-tgc-fm_20050101
238
 
239
would be appropriate if the branch was created on January 1st, 2005.
240
 
241
Having selected the branch name, create the branch as follows:
242
 
243
1. Check out binutils, so that you have a CVS checkout corresponding
244
   to the initial state of your branch.
245
 
246
2. Create a tag:
247
 
248
     cvs tag binutils---branchpoint
249
 
250
   That tag will allow you, and others, to easily determine what's
251
   changed on the branch relative to the initial state.
252
 
253
3. Create the branch:
254
 
255
     cvs rtag -b -r binutils---branchpoint \
256
       binutils---branch
257
 
258
4. Document the branch:
259
 
260
     Add a description of the branch to binutils/BRANCHES, and check
261
     that file in.  All branch descriptions should be added to the
262
     HEAD revision of the file; it doesn't help to modify
263
     binutils/BRANCHES on a branch!
264
 
265
Please do not commit any patches to a branch you did not create
266
without the explicit permission of the person who created the branch.

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.