Re: gdb-patches Digest 19 Jan 2001 14:34:08 -0000 Issue 519

[Jim Ingham <jingham at apple dot com>]

Eli,

I think the situation was a little different than you are percieving.

Some patches were checked in.  I also didn't follow the discussion 
closely at the time.  Apparently the patches were controversial, and 
there was some contention about whether they should stay in or not.  But 
for the nonce they were in.  And given that we mostly know that JimB is 
working on another very important and cool project right now (how is 
subversions going by the way) it was clear that it would take a little 
while to sort this out.

HOWEVER, the patch (and thus the current state of gdb) had an obvious 
gaffe that caused gdb to crash in a pretty common usage.  Moreover, 
apparently both the bug and the fix were known pretty soon after the 
original patch was checked in.  To make matters worse, the fix for the 
crashing bug was a no-brainer - probably just a cut & paste error.

So it was important to decouple the discussion of whether the overall 
patch should be reverted or not from the decision to check in a fix that 
kept gdb as it stood in the CVS repository from crashing on people.

This sort of case may very well arise again, since it was not the result 
of bad will on anybody's part, as far as I can tell.  And regardless of 
larger design concerns we really should have a way to expedite fixes in 
this context, so that gdb stays pretty reliable most of the time.  It 
was unreliable for C++ debugging for two or three months.  This is bad...

Jim

>> Date: Thu, 18 Jan 2001 13:32:30 -0500 (EST)
>> From: Daniel Berlin <dberlin@redhat.com>
>>>
>>> I agree.  I was really thinking of this as a special case situation 
>>> where
>>> we could get patches into gdb when the patch maintainer is 
>>> inexplicably
>>> absent.
>>>
>>> If *anyone* disagrees with the patch then it shouldn't go in.
>>
>> Of course. But you have to admit, the situation we just had, as Jim
>> pointed out, makes GDB look *really* bad.
>
> I don't agree.  I didn't follow the discussion about this particular
> problem, but if the relevant maintainer goes off-line, and some of the
> other maintainers have reservations about a suggested patch in the
> absent maintainer's area, refraining from committing that patch is
> IMHO a prudent thing to do.
>
> In such a situation, you have several possible alternatives:
>
>   - talk the opposition into agreeing to the patch;
>   - suggest an alternative patch which avoids the problems which
>     triggered the opposition;
>   - wait for the maintainer to reappear and decide what to do.

--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer