gdb-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gdbheads] proposed change to GDB maintainership rules


From: Andrew Cagney
Subject: Re: [Gdbheads] proposed change to GDB maintainership rules
Date: Fri, 30 Jan 2004 13:36:34 -0500
User-agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820

Andrew Cagney <address@hidden> writes:


> Andrew, I'm having a hard time working out precisely what you are
> saying, so, just to be crystal clear: do you object to that part of
> the proposed change in the e-mail from Kevin Buettner, to wit, that
> any global maintainer may approve any patch, even to an area which has
> an area maintainer?


I'm trying to compare the two systems, and note the benefits offered
by the current GDB.


That's fine, but you haven't answered my question.

Do you have an answer?

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.

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.

Either way, the thing to study, is what happens when things go wrong.

In GCC, people complain, and the global maintainers step in.


And ultimately, in principle, the steering committee makes a decision.
That doesn't happen very often, though.



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.

>  There are
> other proposals on the table; do you agree with them, or do you have
> any suggestions?

I'll reply to this separatly.

Andrew






reply via email to

[Prev in Thread] Current Thread [Next in Thread]