Re: [maint] The GDB maintenance process

[Andrew Cagney <ac131313@redhat.com>]

> I agree with what Daniel has said here.  I'm concerned that some
> people have misunderstood his points, so I'll put it differently.
> 
> I think GDB could get better use of the contributors it has now by
> adjusting the rules for patch approval.
> 
> - Slow patch review is a real problem on GDB --- even acknowledging
>   the legitimate reasons for some delays that Elena has mentioned.

I found myself babysitting a short list of largely dormant maintainers 
using regular pings.  That was grosely inefficient.  I've now given that 
one up and have moved on to filing unreviewed patches in the bug 
database - worse for the contributor waiting on a dormant maintainer but 
better for me and the other active maintainers.

It has been in place for ~a month and, in my opinion, has definitly 
improved things.  There is a one-stop-shop where active [global] 
maintainers can either find a backlog of patches or areas that need work.

I just wish that the tool being used was less primative :-(

> - 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.  Folks have been saying that ever since
>   Cygnus loosened its grip on GDB and the process opened to the
>   public.  That statement seems to express a hope that the maintainers
>   will somehow "wake up" and everything will get better.  It's been
>   years, now, and we need to stop waiting for this to happen.  Let's
>   work with the people we've got, rather than hoping they'll transform
>   themselves somehow.

And the vast majority of maintainers do a pretty good job.

> - If we accept that the maintainers' behavior is stable, then the next
>   alternative is to adjust the organization that they operate under.
>   Is there some way to re-organize the people we have, accepting their
>   job committments and personal limitations (I have myself in mind
>   here as much as anyone else, so don't be affronted), so that things
>   progress better?  Is the current organization optimal?

Stable or reliable?  Most maintainers are reliable, a small few, though, 
seem to keep falling asleep at the wheel.

Having such people as developers isn't a problem.  Having such people 
hold key responsabilities (such as being in the loop to review patches) is.

Andrew