Maintainers list

[DJ Delorie <dj at delorie dot com>]

Given the popularity of gcc and the growing number of contributors,
it's no surprise that people have been complaining about patches going
unreviewed for long periods of time ("falling through the cracks").  I
understand that gcc is maintained by volunteers who are busy doing gcc
work in addition to their regular life.  It would be best if
contributors "championed" their own patches, but the available
information is minimal about how to do that.

To address this, I have some ideas:

* The MAINTAINERS file lists all the maintainers, but it's often
  unclear which ones to contact if you can't get a response from the
  mailing list.  Especially when a "various maintainer" is also a
  "blanket write privs" maintainer and is thus likely to be very busy.
  Would it be worthwhile to put the effort into expanding the
  MAINTAINERS file to assist contributors, perhaps by giving explicit
  file names instead of "foo port" or "bar feature"?  Or maybe a
  statement at the top like "If you are reading this because you're
  submitting a patch..."?

* Perhaps a maintainer is different from a point of contact.  Just
  because A is a maintainer for a file, doesn't mean that A is the
  right person to bug about reviewing patches.

* Perhaps each file should be tagged with an origin and a list of
  maintainers, in the order you should try to contact them?  Something
  like this kind of comment:

	/* %% Master: gnu.gcc.org:/cvs/egcs %% */
	/* %% Maintainer: J Random Hacker <jrandom@hacker.net> %% */
	/* %% Maintainer: John Doe <johndoe@aol.com> %% */

  However, this may cause excessive personal email, which would be bad.

* The contribute.html page should include an example email to use when
  following up to an unreviewed patch.  Having a standard subject
  (example: "Follow-up to unreviewed patch") would make it easy for
  maintainers to catch it the second time around.  It should also
  suggest subject line conventions for the initial patch, like
  "[patch] file.c file.h" so that the maintainers can quickly
  determine if they should respond to it.

I had also thought of a program that monitored gcc-patches and tried
to guess when a patch went unreviewed, but the technical hurdles are
pretty high for something like that.

Comments?  Other ideas?