Re: [maint] The GDB maintenance process

[Jim Blandy <jimb@redhat.com>]

Andrew Cagney <ac131313@redhat.com> writes:

> > - It's true that "... some maintainers should try to review patches in
> >   their areas of responsibility more often", but merely saying so
> >   doesn't have any effect.
> 
> For the record your name is top of the list of that `some maintainers'.

If you like.  I pick on myself often enough elsewhere in that message
that it should be clear I'm not trying to make others feel bad for
shortcomings I have myself.

In fact, this is exactly what we need to put behind us: we can spend
another few years feeling bad for being insufficiently responsive, and
treating it as a personal failure.  But that approach hasn't improved
things noticeably, so, is there something else we can do?  Given the
people we have, the community we have, and their known strengths and
weaknesses, what is the best way to organize them?  Can we improve on
what we're doing now?

I think the explicit hierarchy we have now, outlined in MAINTAINERS,
is a real problem in this sense.  It's a big, public, political deal
to rearrange that hierarchy.  There are other systems where the
processes of promoting promising contributors and clearing dead wood
happen smoothly and automatically, without confrontation.  People
contribute as they are able, and leaders emerge and recede in a
natural way, not by fiat.  The Apache system, for example, encourages
newcomers to acquire expertise in different areas, and allows less
responsive people to simply fall to the wayside as irrelevant.

These systems are in widespread use, and I think some are even
well-documented, like: http://httpd.apache.org/dev/guidelines.html