+For documentation changes, about the only kind of fix that is obvious
+is correction of a typo or bad English usage.
+
+
+ GDB Steering Committee
+ ----------------------
+
+The members of the GDB Steering Committee are the FSF-appointed
+maintainers 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 FSF
+requests. However, they are generally not involved in day-to-day
+development.
+
+The current members of the steering committee are listed below, in
+alphabetical order. Their affiliations are provided for reference only -
+their membership on the Steering Committee is individual and not through
+their 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 Whitesel
+
+
+ Global Maintainers
+ ------------------
+
+The global maintainers may review and commit any change to GDB, except in
+areas with a Responsible Maintainer available. For major changes, or
+changes to areas with other active developers, global maintainers are
+strongly encouraged to post their own patches for feedback before
+committing.
+
+The global maintainers are responsible for reviewing patches to any area
+for which no Responsible Maintainer is listed.
+
+Global maintainers also have the authority to revert patches which should
+not have been applied, e.g. patches which were not approved, controversial
+patches committed under the Obvious Fix Rule, patches with important bugs
+that can't be immediately fixed, or patches which go against an accepted and
+documented roadmap for GDB development. Any global maintainer may request
+the reversion of a patch. If no global maintainer, or responsible
+maintainer in the affected areas, supports the patch (except for the
+maintainer who originally committed it), then after 48 hours the maintainer
+who called for the reversion may revert the patch.
+
+No one may reapply a reverted patch without the agreement of the maintainer
+who reverted it, or bringing the issue to the GDB Steering Committee for
+discussion.
+
+At the moment there are no documented roadmaps for GDB development; in the
+future, if there are, a reference to the list will be included here.
+
+The current global maintainers are (in alphabetical order):
+
+Jim Blandy jimb@mozilla.com
+Joel Brobecker brobecker@adacore.com
+Kevin Buettner kevinb@redhat.com
+Andrew Cagney cagney@gnu.org
+Daniel Jacobowitz dan@debian.org
+Mark Kettenis kettenis@gnu.org
+Stan Shebs stan@codesourcery.com
+Michael Snyder msnyder@specifix.com
+Ulrich Weigand Ulrich.Weigand@de.ibm.com
+Elena Zannoni ezannoni@redhat.com
+Eli Zaretskii eliz@gnu.org
+
+
+ Release 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. They
+endeavor to prevent any posted patch from being overlooked; work with
+contributors to meet GDB's coding style and general requirements, along with
+FSF copyright assignments; remind (ping) responsible maintainers to review
+patches; 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, in
+which they have knowledge and experience. These areas are generally broad;
+the role of a responsible maintainer is to provide coherent and cohesive
+structure within their area of GDB, to assure that patches from many
+different 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 that
+responsible maintainers agree to review submitted patches in their area
+promptly; patches and followups should generally be answered within a week.
+If a responsible maintainer is interested in reviewing a patch but will not
+have time within a week of posting, the maintainer should send an
+acknowledgement of the patch to the gdb-patches mailing list, and
+plan to follow up with a review within a month. These deadlines are for
+initial responses to a patch - if the maintainer has suggestions
+or questions, it may take an extended discussion before the patch
+is 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 global
+maintainer may step in to review the patch. But sometimes life intervenes
+more permanently, and a maintainer may no longer have time for these duties.
+When this happens, he or she should step down (either into the Authorized
+Committers section if still interested in the area, or simply removed from
+the list of Responsible Maintainers if not).
+
+If a responsible maintainer is unresponsive for an extended period of time
+without stepping down, please contact the Global Maintainers; they will try
+to contact the maintainer directly and fix the problem - potentially by
+removing that maintainer from their listed position.
+
+If there are several maintainers for a given domain then any one of them
+may review a submitted patch.