URL
https://opencores.org/ocsvn/openrisc_me/openrisc_me/trunk
Subversion Repositories openrisc_me
[/] [openrisc/] [trunk/] [gnu-src/] [gdb-7.2/] [gdb/] [MAINTAINERS] - Rev 478
Go to most recent revision | Compare with Previous | Blame | View Log
GDB Maintainers===============Overview--------This file describes different groups of people who are, together, themaintainers and developers of the GDB project. Don't worry - it soundsmore complicated than it really is.There are four groups of GDB developers, covering the patch development andreview process:- The Global Maintainers.These are the developers in charge of most daily development. Theyhave wide authority to apply and reject patches, but defer to theResponsible Maintainers (see below) within their spheres ofresponsibility.- The Responsible Maintainers.These are developers who have expertise and interest in a particulararea of GDB, who are generally available to review patches, and whoprefer to enforce a single vision within their areas.- The Authorized Committers.These are developers who are trusted to make changes within a specificarea of GDB without additional oversight.- The Write After Approval Maintainers.These are developers who have write access to the GDB source tree. Theycan check in their own changes once a developer with the appropriateauthority has approved the changes; they can also apply the ObviousFix Rule (below).All maintainers are encouraged to post major patches to the gdb-patchesmailing list for comments, even if they have the authority to commit thepatch without review from another maintainer. This especially includespatches which change internal interfaces (e.g. global functions, datastructures) or external interfaces (e.g. user, remote, MI, et cetera).The term "review" is used in this file to describe several kinds of feedbackfrom a maintainer: approval, rejection, and requests for changes orclarification with the intention of approving a revised version. Review isa privilege and/or responsibility of various positions among the GDBMaintainers. Of course, anyone - whether they hold a position but not therelevant one for a particular patch, or are just following along on themailing lists for fun, or anything in between - may suggest changes orask questions about a patch!There's also a couple of other people who play special roles in the GDBcommunity, separately from the patch process:- The GDB Steering Committee.These are the official (FSF-appointed) maintainers of GDB. They havefinal and overriding authority for all GDB-related decisions, includinganything described in this file. The committee is not generallyinvolved in day-to-day development (although its members may be, asindividuals).- The Release Manager.This developer is in charge of making new releases of GDB.- The Patch Champions.These volunteers make sure that no contribution is overlooked orforgotten.Most changes to the list of maintainers in this file are handled byconsensus among the global maintainers and any other involved parties.In cases where consensus can not be reached, the global maintainers mayask the Steering Committee for a final decision.The Obvious Fix Rule--------------------All maintainers listed in this file, including the Write After Approvaldevelopers, are allowed to check in obvious fixes.An "obvious fix" means that there is no possibility that anyone willdisagree with the change.A good mental test is "will the person who hates my work the most beable to find fault with the change" - if so, then it's not obvious andneeds to be posted first. :-)Something like changing or bypassing an interface is _not_ an obviousfix, since such a change without discussion will result ininstantaneous and loud complaints.For documentation changes, about the only kind of fix that is obviousis correction of a typo or bad English usage.GDB Steering Committee----------------------The members of the GDB Steering Committee are the FSF-appointedmaintainers of the GDB project.The Steering Committee has final authority for all GDB-related topics;they may make whatever changes that they deem necessary, or that the FSFrequests. However, they are generally not involved in day-to-daydevelopment.The current members of the steering committee are listed below, inalphabetical order. Their affiliations are provided for reference only -their membership on the Steering Committee is individual and not throughtheir affiliation, and they act on behalf of the GNU project.Jim Blandy (Mozilla)Andrew Cagney (Red Hat)Robert Dewar (AdaCore, NYU)Klee Dienes (Apple)Paul Hilfinger (UC Berkeley)Dan Jacobowitz (CodeSourcery)Stan Shebs (CodeSourcery)Richard Stallman (FSF)Ian Lance Taylor (C2)Todd WhiteselGlobal Maintainers------------------The global maintainers may review and commit any change to GDB, except inareas with a Responsible Maintainer available. For major changes, orchanges to areas with other active developers, global maintainers arestrongly encouraged to post their own patches for feedback beforecommitting.The global maintainers are responsible for reviewing patches to any areafor which no Responsible Maintainer is listed.Global maintainers also have the authority to revert patches which shouldnot have been applied, e.g. patches which were not approved, controversialpatches committed under the Obvious Fix Rule, patches with important bugsthat can't be immediately fixed, or patches which go against an accepted anddocumented roadmap for GDB development. Any global maintainer may requestthe reversion of a patch. If no global maintainer, or responsiblemaintainer in the affected areas, supports the patch (except for themaintainer who originally committed it), then after 48 hours the maintainerwho called for the reversion may revert the patch.No one may reapply a reverted patch without the agreement of the maintainerwho reverted it, or bringing the issue to the GDB Steering Committee fordiscussion.At the moment there are no documented roadmaps for GDB development; in thefuture, if there are, a reference to the list will be included here.The current global maintainers are (in alphabetical order):Pedro Alves pedro@codesourcery.comJim Blandy jimb@red-bean.comJoel Brobecker brobecker@adacore.comKevin Buettner kevinb@redhat.comAndrew Cagney cagney@gnu.orgDoug Evans dje@google.comDaniel Jacobowitz dan@codesourcery.comMark Kettenis kettenis@gnu.orgStan Shebs stan@codesourcery.comMichael Snyder msnyder@vmware.comTom Tromey tromey@redhat.comUlrich Weigand Ulrich.Weigand@de.ibm.comElena Zannoni elena.zannoni@oracle.comEli Zaretskii eliz@gnu.orgRelease Manager---------------The current release manager is: Joel Brobecker <brobecker@adacore.com>His responsibilities are:* organizing, scheduling, and managing releases of GDB.* deciding the approval and commit policies for release branches,and can change them as needed.Patch Champions---------------These volunteers track all patches submitted to the gdb-patches list. Theyendeavor to prevent any posted patch from being overlooked; work withcontributors to meet GDB's coding style and general requirements, along withFSF copyright assignments; remind (ping) responsible maintainers to reviewpatches; and ensure that contributors are given credit.Current patch champions (in alphabetical order):Randolph Chung <tausq@debian.org>Responsible Maintainers-----------------------These developers have agreed to review patches in specific areas of GDB, inwhich they have knowledge and experience. These areas are generally broad;the role of a responsible maintainer is to provide coherent and cohesivestructure within their area of GDB, to assure that patches from manydifferent contributors all work together for the best results.Global maintainers will defer to responsible maintainers within their areas,as long as the responsible maintainer is active. Active means thatresponsible maintainers agree to review submitted patches in their areapromptly; patches and followups should generally be answered within a week.If a responsible maintainer is interested in reviewing a patch but will nothave time within a week of posting, the maintainer should send anacknowledgement of the patch to the gdb-patches mailing list, andplan to follow up with a review within a month. These deadlines are forinitial responses to a patch - if the maintainer has suggestionsor questions, it may take an extended discussion before the patchis ready to commit. There are no written requirements for discussion,but maintainers are asked to be responsive.If a responsible maintainer misses these deadlines occasionally (e.g.vacation or unexpected workload), it's not a disaster - any globalmaintainer may step in to review the patch. But sometimes life intervenesmore permanently, and a maintainer may no longer have time for these duties.When this happens, he or she should step down (either into the AuthorizedCommitters section if still interested in the area, or simply removed fromthe list of Responsible Maintainers if not).If a responsible maintainer is unresponsive for an extended period of timewithout stepping down, please contact the Global Maintainers; they will tryto contact the maintainer directly and fix the problem - potentially byremoving that maintainer from their listed position.If there are several maintainers for a given domain then any one of themmay review a submitted patch.Target Instruction Set Architectures:The *-tdep.c files. ISA (Instruction Set Architecture) and OS-ABI(Operating System / Application Binary Interface) issues including CPUvariants.The Target/Architecture maintainer works with the host maintainer whenresolving build issues. The Target/Architecture maintainer works withthe native maintainer when resolving ABI issues.alpha --target=alpha-elf ,-Werrorarm --target=arm-elf ,-WerrorRichard Earnshaw rearnsha@arm.comavr --target=avr ,-WerrorTristan Gingold gingold@adacore.comcris --target=cris-elf ,-Werror ,(sim does not build with -Werror)frv --target=frv-elf ,-Werrorh8300 --target=h8300-elf ,-Werrori386 --target=i386-elf ,-WerrorMark Kettenis kettenis@gnu.orgia64 --target=ia64-linux-gnu ,-Werror(--target=ia64-elf broken)Jan Kratochvil jan.kratochvil@redhat.comlm32 --target=lm32-elf ,-Werrorm32c --target=m32c-elf ,-Werrorm32r --target=m32r-elf ,-Werrorm68hc11 --target=m68hc11-elf ,-Werror ,Stephane Carrez stcarrez@nerim.frm68k --target=m68k-elf ,-Werrorm88k --target=m88k-openbsd ,-WerrorMark Kettenis kettenis@gnu.orgmcore Deletedmep --target=mep-elf ,-WerrorKevin Buettner kevinb@redhat.commicroblaze --target=microblaze-xilinx-elf ,-Werror--target=microblaze-linux-gnu ,-WerrorMichael Eager eager@eagercon.commips --target=mips-elf ,-Werrormn10300 --target=mn10300-elf broken(sim/ dies with make -j)Michael Snyder msnyder@vmware.commoxie --target=moxie-elf ,-WerrorAnthony Green green@moxielogic.comms1 --target=ms1-elf ,-WerrorKevin Buettner kevinb@redhat.comns32k Deletedpa --target=hppa-elf ,-Werrorpowerpc --target=powerpc-eabi ,-Werrors390 --target=s390-linux-gnu ,-Werrorscore --target=score-elfQinwei qinwei@sunnorth.com.cnsh --target=sh-elf ,-Werror--target=sh64-elf ,-Werrorsparc --target=sparc64-solaris2.10 ,-Werror(--target=sparc-elf broken)spu --target=spu-elf ,-WerrorUlrich Weigand uweigand@de.ibm.comv850 --target=v850-elf ,-Werrorvax --target=vax-netbsd ,-Werrorx86-64 --target=x86_64-linux-gnu ,-Werrorxstormy16 --target=xstormy16-elfCorinna Vinschen vinschen@redhat.comxtensa --target=xtensa-elfMaxim Grigoriev maxim2405@gmail.comAll developers recognized by this file can make arbitrary changes toOBSOLETE targets.The Bourne shell script gdb_mbuild.sh can be used to rebuild all theabove targets.Host/Native:The Native maintainer is responsible for target specific nativesupport - typically shared libraries and quirks to procfs/ptrace/...The Native maintainer works with the Arch and Core maintainers whenresolving more generic problems.The host maintainer ensures that gdb can be built as a cross debugger ontheir platform.AIX Joel Brobecker brobecker@adacore.comDarwin Tristan Gingold gingold@adacore.comdjgpp native Eli Zaretskii eliz@gnu.orgGNU Hurd Alfred M. Szmidt ams@gnu.orgMS Windows (NT, '00, 9x, Me, XP) host & nativeChris Faylor cgf@alum.bu.eduGNU/Linux/x86 native & hostMark Kettenis kettenis@gnu.orgGNU/Linux MIPS native & hostDaniel Jacobowitz dan@codesourcery.comGNU/Linux m68k Andreas Schwab schwab@linux-m68k.orgFreeBSD native & host Mark Kettenis kettenis@gnu.orgCore: Generic components used by all of GDBtracing Michael Snyder msnyder@vmware.comthreads Michael Snyder msnyder@vmware.comMark Kettenis kettenis@gnu.orglanguage supportAda Joel Brobecker brobecker@adacore.comPaul Hilfinger hilfinger@gnat.comC++ Daniel Jacobowitz dan@codesourcery.comObjective C support Adam Fedor fedor@gnu.orgshared libs Kevin Buettner kevinb@redhat.comMI interface Vladimir Prus vladimir@codesourcery.comdocumentation Eli Zaretskii eliz@gnu.org(including NEWS)testsuitegdbtk (gdb.gdbtk) Keith Seitz keiths@redhat.comthreads (gdb.threads) Michael Snyder msnyder@vmware.comtrace (gdb.trace) Michael Snyder msnyder@vmware.comUI: External (user) interfaces.gdbtk (c & tcl) Fernando Nasser fnasser@redhat.comKeith Seitz keiths@redhat.comlibgui (w/foundry, sn) Keith Seitz keiths@redhat.comMisc:gdb/gdbserver Daniel Jacobowitz dan@codesourcery.comMakefile.in, configure* ALLmmalloc/ ALL Host maintainerssim/ See sim/MAINTAINERSreadline/ Master version: ftp://ftp.cwru.edu/pub/bash/ALLHost maintainers (host dependant parts)(but get your changes into the master version)tcl/ tk/ itcl/ ALLAuthorized Committers---------------------These are developers working on particular areas of GDB, who are trusted tocommit their own (or other developers') patches in those areas withoutfurther review from a Global Maintainer or Responsible Maintainer. They areunder no obligation to review posted patches - but, of course, are invitedto do so!PowerPC Andrew Cagney cagney@gnu.orgCRIS Hans-Peter Nilsson hp@axis.comIA64 Jeff Johnston jjohnstn@redhat.comMIPS Joel Brobecker brobecker@adacore.comm32r Kei Sakamoto sakamoto.kei@renesas.comPowerPC Kevin Buettner kevinb@redhat.comCRIS Orjan Friberg orjanf@axis.comHPPA Randolph Chung tausq@debian.orgS390 Ulrich Weigand uweigand@de.ibm.comdjgpp DJ Delorie dj@delorie.com[Please use this address to contact DJ about DJGPP]tui Stephane Carrez stcarrez@nerim.fria64 Kevin Buettner kevinb@redhat.comAIX Kevin Buettner kevinb@redhat.comGNU/Linux PPC native Kevin Buettner kevinb@redhat.comgdb.java tests Anthony Green green@redhat.comFreeBSD native & host David O'Brien obrien@freebsd.orgevent loop Elena Zannoni elena.zannoni@oracle.comgeneric symtabs Elena Zannoni elena.zannoni@oracle.comdwarf readers Elena Zannoni elena.zannoni@oracle.comelf reader Elena Zannoni elena.zannoni@oracle.comstabs reader Elena Zannoni elena.zannoni@oracle.comreadline/ Elena Zannoni elena.zannoni@oracle.comNetBSD native & host Jason Thorpe thorpej@netbsd.orgPascal support Pierre Muller muller@sourceware.orgavr Theodore A. Roth troth@openavr.orgModula-2 support Gaius Mulley gaius@glam.ac.ukWrite After Approval(alphabetic)To get recommended for the Write After Approval list you need a validFSF assignment and have submitted one good patch.Pedro Alves pedro_alves@portugalmail.ptDavid Anderson davea@sgi.comJohn David Anglin dave.anglin@nrc-cnrc.gc.caShrinivas Atre shrinivasa@kpitcummins.comScott Bambrough scottb@netwinder.orgThiago Jung Bauermann bauerman@br.ibm.comJon Beniston jon@beniston.comJan Beulich jbeulich@novell.comJim Blandy jimb@codesourcery.comPhilip Blundell philb@gnu.orgPer Bothner per@bothner.comJoel Brobecker brobecker@adacore.comDave Brolley brolley@redhat.comPaul Brook paul@codesourcery.comJulian Brown julian@codesourcery.comKevin Buettner kevinb@redhat.comAndrew Cagney cagney@gnu.orgDavid Carlton carlton@bactrian.orgStephane Carrez stcarrez@nerim.frMichael Chastain mec.gnu@mindspring.comRenquan Cheng crq@gcc.gnu.orgEric Christopher echristo@apple.comRandolph Chung tausq@debian.orgNick Clifton nickc@redhat.comJ.T. Conklin jtc@acorntoolworks.comBrendan Conoboy blc@redhat.comDJ Delorie dj@redhat.comChris Demetriou cgd@google.comPhilippe De Muyter phdm@macqel.beDhananjay Deshpande dhananjayd@kpitcummins.comMarkus Deuling deuling@de.ibm.comKlee Dienes kdienes@apple.comGabriel Dos Reis gdr@integrable-solutions.netMichael Eager eager@eagercon.comRichard Earnshaw rearnsha@arm.comSteve Ellcey sje@cup.hp.comFrank Ch. Eigler fche@redhat.comBen Elliston bje@gnu.orgDoug Evans dje@google.comAdam Fedor fedor@gnu.orgBrian Ford ford@vss.fsi.comOrjan Friberg orjanf@axis.comNathan Froyd froydnj@codesourcery.comGary Funck gary@intrepid.comPaul Gilliam pgilliam@us.ibm.comTristan Gingold gingold@adacore.comRaoul Gough RaoulGough@yahoo.co.ukAnthony Green green@redhat.comMatthew Green mrg@eterna.com.auMatthew Gretton-Dann matthew.gretton-dann@arm.comMaxim Grigoriev maxim2405@gmail.comJerome Guitton guitton@act-europe.frBen Harris bjh21@netbsd.orgRichard Henderson rth@redhat.comAldy Hernandez aldyh@redhat.comPaul Hilfinger hilfinger@gnat.comMatt Hiller hiller@redhat.comKazu Hirata kazu@cs.umass.eduJeff Holcomb jeffh@redhat.comDon Howard dhoward@redhat.comNick Hudson nick.hudson@dsl.pipex.comMartin Hunt hunt@redhat.comJim Ingham jingham@apple.comBaurzhan Ismagulov ibr@radix50.netManoj Iyer manjo@austin.ibm.comDaniel Jacobowitz dan@codesourcery.comAndreas Jaeger aj@suse.deJeff Johnston jjohnstn@redhat.comGeoff Keating geoffk@redhat.comMark Kettenis kettenis@gnu.orgMarc Khouzam marc.khouzam@ericsson.comJim Kingdon kingdon@panix.comJan Kratochvil jan.kratochvil@redhat.comJonathan Larmour jifl@ecoscentric.comJeff Law law@redhat.comDavid Lecomber david@streamline-computing.comDon Lee don.lee@sunplusct.comRobert Lipe rjl@sco.comSandra Loosemore sandra@codesourcery.comH.J. Lu hjl.tools@gmail.comMichal Ludvig mludvig@suse.czLuis Machado luisgpm@br.ibm.comGlen McCready gkm@redhat.comGreg McGary greg@mcgary.orgRoland McGrath roland@redhat.comBryce McKinlay mckinlay@redhat.comJason Merrill jason@redhat.comDavid S. Miller davem@redhat.comMark Mitchell mark@codesourcery.comMarko Mlinar markom@opencores.orgAlan Modra amodra@gmail.comJason Molenda jmolenda@apple.comChris Moller cmoller@redhat.comPhil Muldoon pmuldoon@redhat.comPierre Muller muller@sourceware.orgGaius Mulley gaius@glam.ac.ukJoseph Myers joseph@codesourcery.comFernando Nasser fnasser@redhat.comAdam Nemet anemet@caviumnetworks.comNathanael Nerode neroden@gcc.gnu.orgHans-Peter Nilsson hp@bitrange.comDavid O'Brien obrien@freebsd.orgAlexandre Oliva aoliva@redhat.comKaren Osmond karen.osmond@gmail.comDenis Pilat denis.pilat@st.comPaul Pluzhnikov ppluzhnikov@google.comVladimir Prus vladimir@codesourcery.comQinwei qinwei@sunnorth.com.cnFrederic Riss frederic.riss@st.comAleksandar Ristovski aristovski@qnx.comTom Rix trix@redhat.comNick Roberts nickrob@snap.net.nzBob Rossi bob_rossi@cox.netTheodore A. Roth troth@openavr.orgIan Roxborough irox@redhat.comMaciej W. Rozycki macro@linux-mips.orgGrace Sainsbury graces@redhat.comKei Sakamoto sakamoto.kei@renesas.comMark Salter msalter@redhat.comRichard Sandiford richard@codesourcery.comPeter Schauer Peter.Schauer@mytum.deAndreas Schwab schwab@linux-m68k.orgThomas Schwinge tschwinge@gnu.orgKeith Seitz keiths@redhat.comCarlos Eduardo Seo cseo@linux.vnet.ibm.comOzkan Sezer sezeroz@gmail.comStan Shebs stan@codesourcery.comJoel Sherrill joel.sherrill@oarcorp.comMark Shinwell shinwell@codesourcery.comCraig Silverstein csilvers@google.comAidan Skinner aidan@velvet.netJiri Smid smid@suse.czDavid Smith dsmith@redhat.comStephen P. Smith ischis2@cox.netJackie Smith Cashion jsmith@redhat.comMichael Snyder msnyder@vmware.comPetr Sorfa petrs@caldera.comAndrew Stubbs ams@codesourcery.comEmi Suzuki emi-suzuki@tjsys.co.jpIan Lance Taylor ian@airs.comGary Thomas gthomas@redhat.comJason Thorpe thorpej@netbsd.orgCaroline Tice ctice@apple.comKai Tietz kai.tietz@onevision.comTom Tromey tromey@redhat.comDavid Ung davidu@mips.comD Venkatasubramanian dvenkat@noida.hcltech.comCorinna Vinschen vinschen@redhat.comSami Wagiaalla swagiaal@redhat.comKeith Walker keith.walker@arm.comKris Warkentin kewarken@qnx.comUlrich Weigand uweigand@de.ibm.comNathan Williams nathanw@wasabisystems.comBob Wilson bob.wilson@acm.orgJim Wilson wilson@tuliptree.orgElena Zannoni elena.zannoni@oracle.comEli Zaretskii eliz@gnu.orgJie Zhang jie@codesourcery.comWu Zhou woodzltc@cn.ibm.comYoshinori Sato ysato@users.sourceforge.jpHui Zhu teawater@gmail.comSergio Durigan Junior sergiodj@linux.vnet.ibm.comMasaki Muranaka monaka@monami-software.comPast MaintainersWhenever removing yourself, or someone else, from this file, considerlisting their areas of development here for posterity.Jimmy Guo (gdb.hp, tui) guo at cup dot hp dot comJeff Law (hppa) law at cygnus dot comDaniel Berlin (C++ support) dan at cgsoftware dot comNick Duffek (powerpc, SCO, Sol/x86) nick at duffek dot comDavid Taylor (d10v, sparc, utils, defs,expression evaluator, language support) taylor at candd dot orgJ.T. Conklin (dcache, NetBSD, remote, global) jtc at acorntoolworks dot comFrank Ch. Eigler (sim) fche at redhat dot comPer Bothner (Java) per at bothner dot comAnthony Green (Java) green at redhat dot comFernando Nasser (testsuite/, mi, cli, KOD) fnasser at redhat dot comMark Salter (testsuite/lib+config) msalter at redhat dot comJim Kingdon (web pages) kingdon at panix dot comJim Ingham (gdbtk, libgui) jingham at apple dot comMark Kettenis (hurd native) kettenis at gnu dot orgIan Roxborough (in-tree tcl, tk, itcl) irox at redhat dot comRobert Lipe (SCO/Unixware) rjl at sco dot comPeter Schauer (global, AIX, xcoffsolib,Solaris/x86) Peter.Schauer at mytum dot deScott Bambrough (ARM) scottb at netwinder dot orgPhilippe De Muyter (coff) phdm at macqel dot beMichael Chastain (testsuite) mec.gnu at mindspring dot comFred Fish (global)Folks that have been caught up in a paper trail:David Carlton carlton@bactrian.orgRamana Radhakrishnan ramana.r@gmail.com;; Local Variables:;; coding: utf-8;; End:
Go to most recent revision | Compare with Previous | Blame | View Log
