Re: [maint] GDB needs more local maintainers

[David Carlton <carlton at math dot stanford dot edu>]

On Wed, 26 Feb 2003 12:03:49 -0500, Andrew Cagney <ac131313 at redhat dot com> said:

> At one point, in the deep dark past the `solution' adopted was to
> `throw more maintainers at the problem'.  If you think this is
> starting to sound like `throwing more programmers at the problem'
> then it is :-(

My understanding is that the reasons why "throwing more programmers at
the problem" is a bad idea are, roughly speaking, as follows:

* New programmers need training time to come up to speed; not only
  does this mean that the extra programmers aren't as effective as the
  earlier programmers, but the earlier programmers actually become
  less effective as well because they have to spend time training the
  newbies.

* If the work that is to be done is too atomic, then multiple people
  can't simultaneously do the work effectively.

I don't see why either of those problems should arise when adding new
maintainers.

> One thing that has changed since then is for for developers to
> recognize that that while they might have a short (weeks) to medium
> (months) term interest in a specific aspect of GDB, they don't have
> the level of commitment needed to maintain that body of code.

> This is why the maintainers file contains things like: send tricky
> ones to person XXX; or person XXX can make changes.  While XXX can
> take certain liberties it is clear that `the buck' doesn't stop with
> them.  A more senior maintainer is free to approve/make changes.  I
> would be wasting my time if I try to chase after them with a patch.

This is more to the core of the issue.  The maintainers right now have
two or three functions:

1) They can make changes to the code in question without needing as
   much approval as non-maintainers.

2) They can approve others' changes to the code.

3) They should, ideally, actually maintain the code, in the sense of
   overseeing its future development, getting rid of structural flaws
   in the code, weeding out bit rot and thorny code, etc.

Long term commitment is necessary for part 3; long term commitment is
not necessary for parts 1 and 2.  If you want to be trusted to make
changes to a body of code, what is important is whether or not you are
familiar with the issues impacting the code right now, not whether or
not you'll still be around in a couple of years.  Obviously your
judgment about what changes are appropriate now should be informed by
a desire for the code to be healthy in a couple of years, but that
doesn't actually mean you actually have to plan to stick around for
another couple of years.

If we wanted to try to split off these three roles into a few
different categories (senior maintainers and junior maintainers, or
whatever), fine; I don't think that level of bureaucracy would be
useful, but maybe I'm wrong.  But what I do claim is:

* There are many people contributing to GDB right now who aren't
  recognized as maintainers in areas even though they're competent in
  areas 1) and 2) above.

* In practice, maintainers don't do function 3).  (With exceptions, of
  course: Eli comes to mind as a wonderfully proactive documentation
  maintainer.)  Long-term fixes typically get made whenever their
  absence is causing somebody problems; the person doing that fix may
  be a maintainer, or may not.

If your criterion for being a maintainer is to "have the level of
commitment needed to maintain that body of code", you'd have to empty
out almost all of the current MAINTAINERS file, and you wouldn't find
anybody to replace them.

> This is also why I try to encourage developers (remember I also act
> in that role) to discuss / negotiate technical issues up front.

Of course this is a good idea.  But, I continue (with my mania for
bullet points):

* People can/should/will and talk with others about technical issues
  whether or not they're maintainers.

* Negotiating those issues in advance is great if you can get somebody
  to listen to you in the first place, and if the technical issues are
  such that they can be discussed without a concrete patch.  That's
  frequently not the case.

Obviously, I'm a newbie here, so I can't really speak from experience:
all I can do is make suggestions that seem to make sense from my
limited perspective.  But if you go back to the responses to Daniel's
original message, a majority of the participants agree with him that
there's a problem that won't be fixed simply by making it easier to
track patches, or by nagging maintainers to be more responsive.  And
some of those people agreeing with him _do_ have a lot of experience
with GDB, and with other software products with different, effective
maintenance strategies.

David Carlton
carlton at math dot stanford dot edu