+ ===============
+
+
+ Overview
+ --------
+
+This file describes different groups of people who are, together, the
+maintainers and developers of the GDB project. Don't worry - it sounds
+more complicated than it really is.
+
+There are four groups of GDB developers, covering the patch development and
+review process:
+
+ - The Global Maintainers.
+
+ These are the developers in charge of most daily development. They
+ have wide authority to apply and reject patches, but defer to the
+ Responsible Maintainers (see below) within their spheres of
+ responsibility.
+
+ - The Responsible Maintainers.
+
+ These are developers who have expertise and interest in a particular
+ area of GDB, who are generally available to review patches, and who
+ prefer to enforce a single vision within their areas.
+
+ - The Authorized Committers.
+
+ These are developers who are trusted to make changes within a specific
+ area of GDB without additional oversight.
+
+ - The Write After Approval Maintainers.
+
+ These are developers who have write access to the GDB source tree. They
+ can check in their own changes once a developer with the appropriate
+ authority has approved the changes; they can also apply the Obvious
+ Fix Rule (below).
+
+All maintainers are encouraged to post major patches to the gdb-patches
+mailing list for comments, even if they have the authority to commit the
+patch without review from another maintainer. This especially includes
+patches which change internal interfaces (e.g. global functions, data
+structures) or external interfaces (e.g. user, remote, MI, et cetera).
+
+The term "review" is used in this file to describe several kinds of feedback
+from a maintainer: approval, rejection, and requests for changes or
+clarification with the intention of approving a revised version. Review is
+a privilege and/or responsibility of various positions among the GDB
+Maintainers. Of course, anyone - whether they hold a position but not the
+relevant one for a particular patch, or are just following along on the
+mailing lists for fun, or anything in between - may suggest changes or
+ask questions about a patch!
+
+There's also a couple of other people who play special roles in the GDB
+community, separately from the patch process:
+
+ - The GDB Steering Committee.
+
+ These are the official (FSF-appointed) maintainers of GDB. They have
+ final and overriding authority for all GDB-related decisions, including
+ anything described in this file. The committee is not generally
+ involved in day-to-day development (although its members may be, as
+ individuals).
+
+ - 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 or
+ forgotten.
+
+Most changes to the list of maintainers in this file are handled by
+consensus among the global maintainers and any other involved parties.
+In cases where consensus can not be reached, the global maintainers may
+ask the Steering Committee for a final decision.
+
+
+ The Obvious Fix Rule
+ --------------------
+
+All maintainers listed in this file, including the Write After Approval
+developers, are allowed to check in obvious fixes.
+
+An "obvious fix" means that there is no possibility that anyone will
+disagree with the change.
+
+A good mental test is "will the person who hates my work the most be
+able to find fault with the change" - if so, then it's not obvious and
+needs to be posted first. :-)
+
+Something like changing or bypassing an interface is _not_ an obvious
+fix, since such a change without discussion will result in
+instantaneous and loud complaints.
+
+For documentation changes, about the only kind of fix that is obvious
+is correction of a typo or bad English usage.
+