[rfc] yet another maintainers proposal

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

On Fri, 21 Mar 2003 17:34:23 -0500, Andrew Cagney <ac131313 at redhat dot com> said:

> An inactive maintainer, at some point, be it 6 months, or even two
> years of inactivity, needs recognize that they are no longer
> participating in GDB's day-to-day development and as such should
> probably step back from their maintenance roles.  If doing this
> means that the role becomes vacant then that is a good thing.  This
> is because having no maintainer removes any possible perception that
> the code is, in even the smallest way, being developed or maintained
> (c.f., java).

I certainly agree that having no maintainer in an area is better than
having only inactive maintainers in an area: aside from the perception
issue you mention above, it simply makes it much easier to get patches
approved in that area.

But for areas where maintainers still remain, it's not always clear to
me what the benefit is of removing maintainers.  Right now, being a
maintainer has two possible meanings:

1) It might mean that you are trusted to be able to make changes in
   that area yourself, and to review others' patches in that area.

2) It might mean, in addition to 1), that you actually _will_ review
   others' patches in that area in a timely fashion.

Obviously if somebody doesn't consider themself as fulfilling the
first meaning, then it makes sense for that person to step down as a
maintainer: sometimes (frequently, even) code changes significantly
while you aren't looking, after all.

But if some maintainers maintainers are only serving in role 1,
where's the harm?  A completely inactive maintainer in role 1 doesn't
cause fewer patches to be approved; a sporadically active maintainer
in role 1 will occasionally step in to make changes, and GDB is the
better for it.  For example (and I apologize for naming names here),
right now there are two symtab maintainers; Elena does a better job in
role 2 than Jim does.  But it's still the case that Jim approves
occasional symtab patches, sometimes quite significant ones.

I think it's interesting that you talk about the perception that code
is being maintained above, because that's exactly where the harm of
having maintainers in my role 1 might be: it causes a lot of tension
if there aren't enough maintainers in role 2, because then you never
know when, if ever, a patch will be reviewed.  But, assuming that
there are role 2 maintainers around, I still think it's good to have
role 1 maintainers, and that there are many people who could serve as
role 1 maintainers who currently aren't doing so.

One possible concrete suggestion as to how to bring this about would
be as follows: replace the body of the "Various Maintainers" section
of the MAINTAINERS file with this:


  Maintainers who are marked with an asterisk are considered "lead
  maintainers" for that area; lead maintainers commit to reviewing any
  patches in that area in a reasonably timely fashion.  Maintainers
  who are not lead maintainers are still permitted to approve others'
  patches, but they don't commit to doing so on a regular basis.

  If an area of GDB has no lead maintainers, then global maintainers
  are also permitted to review patches in that area.  Note also that
  maintainers need approval to check in patches outside of the
  immediate area that they maintain.


This would make it clearer what maintainers' responsibilities are
(modulo the vagueness of "in a reasonably timely fashion"), giving
patch submitters a better way of gauging how long it will take a patch
to be reviewed and giving them somebody to nudge if the patch isn't
reviewed.  But having non-lead maintainers would also allow us to get
the most out of the talents and time constraints of people working on
GDB: if, say, Jim is too busy to be a lead maintainer for generic
symtab stuff but has the time to be a lead maintainer for DWARF 2
stuff, then Jim and Elena could both remain maintainers for both
areas, but with only Elena serving as a lead maintainer for generic
symtabs and only Jim serving as a lead maintainer for DWARF 2.  (And
maybe Daniel could get added as a non-lead maintainer for both generic
symtabs and DWARF 2: he's probably too busy to serve as a lead
maintainer in either area, but he seems to me to know both areas well
enough to be trusted to approve patches in them.)

Also, the possibility of having areas with maintainers but without any
lead maintainers would allow us to take advantage of people who know a
section of code well but who don't have time to reliably approve
patches for it, without having their presence as maintainers be an
actual hindrance to getting patches approved.  They can remain as
maintainers, chiming in when they have the time, but the global
maintainers could step in as a fallback position.

David Carlton
carlton at math dot stanford dot edu