Re: [Gdbheads] proposed change to GDB maintainership rules

[Ian Lance Taylor]

Andrew Cagney <address@hidden> writes:

> I object to the idea of a global maintainer automatically and
> instantly having the ability to override an area maintainer (for
> instance by being quick on the trigger with patch approval) - we need
> to be tolerant of small delays in review.

Maintaining a project is a human activity, not an automated one.  We
do not need to write down rules which work perfectly every time.  We
only need enough rules to ensure that things move in the right
direction.

If a global maintainer approves a patch that an area maintainer sees
is incorrect, the area maintainer will have the ability to back out
the patch.  It's a minor problem, not a major one.

Naturally, I agree that global maintainers should be tolerant of small
delays in review.  Moreover, I don't have any reason to think that
they would not be.  But I see no reason that that must be written down
in rules.


> >> In GCC, on the other hand, global developers are able to directly, and
> >> immedatly approve patches - without any need to defer or refer to the
> >> relevant maintainer.  I suspect, however, that there is something of
> >> an unwritten convention?
> > Yes, of course there is.  Everybody acts in a reasonable fashion,
> > using their intelligence, guided by experience.  If somebody does
> > something stupid, they are chastised, and they try not to do it
> > again.
> 
> Good old "common sense".  Sounds good in theory.

It is not only good in theory, it is good in practice.  The process
has been working quite smoothly for both gcc and the binutils for over
five years.  Clearly gdb is not working smoothly, or this discussion
would never have arisen.

Since we have a process which works well for gcc and the binutils, and
a different process which is not working all that well for gdb, I
think the onus here is on you to explain why gdb is different from gcc
and the binutils.  Why shouldn't gdb adopt the working process?


> >> In GDB, people complain, and unfortunatly, there's no short term
> >> relief valve - [typically] I pester the area developer and often I'll
> >> end up helping out short term (fine with me).  A more automatic
> >> mechanism might be of benefit here.
> > Any thoughts as to what that mechanism might look like?
> 
> Honestly, no.  What I would desperatly like is a robust mechanism for
> tracking patches (I always mention the word aegis) so that we could at
> least see the problem.  If we knew a patch hadn't been acted on for N
> days, say, we could let core maintainers pick up the slack.

Why is a formal mechanism better than an informal one?  What real harm
is done by letting core maintainers exercise their judgement?  Isn't
their judgement the reason they became core maintainers in the first
place?

Ian