Re: [maint] The GDB maintenance process

[ac131313 at redhat dot com (Andrew Cagney)]

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

This isn't correct.  The MAINTAINERS file reads:

                        Various Maintainers

  Note individuals who maintain parts of the debugger need approval to
  check in changes outside of the immediate domain that they maintain.

  If there is no maintainer for a given domain then the responsibility
  falls to a global maintainer.

  If there are several maintainers for a given domain then
  responsibility falls to the first maintainer.  The first maintainer is
  free to devolve that responsibility among the other maintainers.

so it makes definite references to `responsibility'.  Put simply, `the
buck stops'.  Perhaps you should ask a different question `is the buck
ignored?' and what should be done if/when it is.

Even though GDB is developed by volunteers, it is entirely reasonable
to expect the volunteers to take their duties seriously.  Monitoring
the bug data base; approving patches; where helpful, contributing to
discussions.  Now that I typically file patches into the bug database,
this should be much easier.

However, what is unreasonable is to place un-realistic expectations on
the said maintainers.  The assumption that a volunteer is working 24x7
and living in north america isn't, for instance, reasonable.  A
significant number of GDB maintainers have real jobs and real
timezones.

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

`write' was a simple typo.  From the outset (i.e., from when I got
handed this job) it was made very clear that neither I, nor any other
global maintainer, could override the decision of a specific
maintainer.

This was, and still is, very important.  It ensures that the area has
a certain level of continuity, and it ensures that I (or another
global maintainer) doesn't ride gunshot over a specific 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.

The interaction dynamics of a committed patch are very different to
those of an unapproved patch.  Once a patch is committed, the person
with objections is, unequestionably, put in the back seat.

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

(ROFL.)

The GCC model involves a number of development phases and the above
comments would only relate to one of those phases.  At other times
increasingly strict controls are placed on what can be
committed/approved.  The GCC group spend a significant (out of
control?)  amount of their time trying to re-stablize GCC for their
releases.

For GDB, on the other hand, interesting development can and does get
approved/committed at any time.  GDB snaps are of such quality that we
can confidently refer someone to current sources for fixes (except
when I have a bad day like today :-).  Further, instead of using
official releases (and as you yourself have done) arbitrary snaps can
even make their way into a distro.

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

The only way I've got my patches into GCC is by acting as a champion
for their cause.  Exactly like Elena described.  Having worked on
other open source projects I'd have to conclude the same also applied
to them.

Sounds like it really is time to drag out "aegis".

Andrew