[maint] The GDB maintenance process

[Andrew Cagney]

> I mostly agree with Daniel here.  We have too many single points of
> failure.  I still have testsuite patches sitting in my tree, dating
> months back since they were never approved.  Similarly, Daniel
> probably has been held back more than once since I wasn't able to
> review threads-related patches in a timely fashion.  I think we should
> allow our global maintainers to approve patches even for parts of GDB
> where we have a specific maintainer, if they feel they have the
> necessary expertise.

Depends on what `single point failure' means.  If you look through the 
MAINTAINERS file you'll notice that all but one of the problem areas is 
double, if not triple maintained.  Even with all that dedundency, 
patches in certain areas continues to stall.  While there might be three 
maintainers, the reality is only one or none are reliable.

The first, and most obvious thing is for the global maintainers to 
review their current number of responsibilities and compare that against 
their actual level of commmitment.  I'm down to just target/arch, 
remote, mips and sim/ppc.

The second, is for maintainers to always be on the lookout for potential 
new maintainers (global or not) and, where possible, step aside to let 
new commers in.

Finally, the GDB `tradition' (that appears to have been forgotten) is to 
up front reach consensus on stuff so that the final patches are trivial 
to review.  cf, the block.[hc] change.

enjoy,
Andrew