[maint] The GDB maintenance process

[Daniel Jacobowitz <drow at mvista dot com>]

I get the feeling I'm already pretty unpopular for some of my opinions on
how GDB maintenane should work.  This isn't going to make it any better, but
I feel it should be said.

I believe that our current process has some problems.  Let me try to
explain.  First, to make sure we're all on the same page...

 What does it mean to be a Global Maintainer, in practice?
  - A certain amount of autonomy in the areas of GDB that no one wants to
    take specific responsibility for.  There's no specific maintainer for
    things like the frame support or the type/value systems.
  - A little more freedom in approving patches to other people's areas of
    GDB - not a lot, but it's definitely there.
    [In practice, this depends on:
     o How much risk you're willing to take of annoying people.
     o How likely other maintainers are to shout at you about it.]
  - Authority to approve patches covering general debugger issues.

 What does it mean to be a maintainer for a specific host/target/subsystem,
 in practice?
  - The authority to approve patches and apply your own patches to that area
    of the debugger.

I'd like everyone to notice one thing missing from the above list.  No one
has the _responsibility_ for approving patches.  This is a volunteer
project, and anyone who's watched it in action for a little while will see
that the volunteers are often busy and distracted.  There's no one who
can handle or should have to handle the responsibilities of patch approval.

Another thing to think about: because of the layout of the above, there is
frequently no one who has the _right_ to approve a patch.  They require
buy-in from a number of additional maintainers.  In addition our volunteers
are often too busy to find time to respond to patches.  This impacts patches
from other maintainers (frequently, but generally a small impact) and from
outside contributors (happens less frequently, but larger impact - most of
these never get approved at all, from what I've seen).


Some other GNU projects have a similar setup and don't have this problem. 
GCC and binutils are my usual examples.  How do they avoid it?  They have a
different definition of global maintainer.  That's what ours used to be
called - Blanket Write Privileges.  The system works a little differently:
  - Maintainers for specific areas of the compiler can commit/approve
    patches to the areas they maintain without buy-in from a blanket
    maintainer.
  - Blanket maintainers can commit/approve patches anywhere without buy-in
    from a specific area maintainer.

[I hope Richard will forgive me for using him as an example and for putting
words in his mouth...] This doesn't replace common sense - you generally
won't find Richard Henderson approving patches to the C++ frontend, because:
  - He knows he isn't familiar with it
  - He knows it has an active set of maintainers at all times

Similarly, just because he can check in patches to any target backend, that
doesn't mean he won't ask a target maintainer to look over it first.  If
someone objects to a patch in their area, he would generally not just check
it in anyway.  If they object to it after he checks it in, the two will
discuss the problem like reasonable people and come to some agreement.


Some noticeable differences between these two models:
  - In the GCC model, more people are able/likely to check in patches which
    break things.
  - But in the GCC model, more people are able/likely to check in patches to
    fix it afterwards.
  - Because more people have the privilege of approving a given patch,
    and fewer people's approvals are needed for any particular patch,
    patches (usually) get approved more quickly.
  - Development can happen more quickly, and does not get slowed to a
    standstill when (say) one of us is pulled off of community GDB work for
    an urgent customer project.  This happens all the time - I've never seen
    all the GDB maintainers with time for GDB at the same time.


Right now, we use stricter policies to prevent problems which cause
breakage.  I think these policies are stifling us.  Loosening them (and
maybe adding a formal patch reversion policy) would let more people fix
problems more easily, as they arise, without slowing development.

If there are people on our Global Maintainer list that we don't think should
be trusted with the extra responsibility of the above, then perhaps we need
to rethink who belongs in that list.  I'm not pointing any fingers - I don't
have anyone in mind, and I've been quite happy working with absolutely all
of the current team.  Just putting the idea out.


I've discussed this general situation with a (small) sampling of other GDB
developers and contributors - enough to know that I'm not alone in my
concerns.  These aren't entirely my own words, either.  I'll let other
people take credit/blame for them if they want to, and if I've represented
their opinions accurately.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer