Re: Maintainers list

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> To address this, I have some ideas:

I'm not on the steering committee, so feel free to ignore my comments
:-)

>   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"?

I doubt it. Who's going to maintain that list?

>   Or maybe a statement at the top like "If you are reading this
>   because you're submitting a patch..."?

I'm not sure how much it would help - why don't you submit a patch in
this respect ?-)

> * 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.

Maintainers, in general, are people that the committee and other
contributors trust to do the right thing. So they are typically the
people who'd be in charge of reviewing the patches, also.

> * Perhaps each file should be tagged with an origin and a list of
>   maintainers, in the order you should try to contact them?

I don't think this would help solving the problem at hand. That list
would also get frequently outdated.

> * 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.

That is a good idea. In fact, maintainers of C++ have been requiring
for a long time that C++ patches have a subject of [C++] (or the
like). Adding "[patch]" is not necessary - patches should be sent to
gcc-patches@gcc.gnu.org (and nothing else should be sent there, except
for discussion of a patch).

> 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.

The easiest thing might be to identify the ChangeLog entry in the
patch, and check whether the entry appears in any of the ChangeLogs.
A program checking that could also check whether patches being
contributed indeed do provide a ChangeLog entry.

> Comments?  Other ideas?

Well, I'd say having more volunteers to review patches, and make
recommendations to maintainers may help - if they a good at that, they
may become maintainers themselves one day :-)

There is a number of standard things to look for in a patch. Like I'm
looking for presence of source code, and reproducability, in bug
reports, these people would look for presence of ChangeLogs, presence
of test cases, conformance to the style guides, fixing only a single
problem, and they would test the patches whether they do what they
promise to do.

Regards,
Martin