This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: gdb-patches Digest 19 Jan 2001 14:34:08 -0000 Issue 519
- To: gdb-patches at sources dot redhat dot com
- Subject: Re: gdb-patches Digest 19 Jan 2001 14:34:08 -0000 Issue 519
- From: Jim Ingham <jingham at apple dot com>
- Date: Fri, 19 Jan 2001 10:49:56 -0800
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