Re: [patch] fix for infinite recursion in lookup_symbol

[Fernando Nasser <fnasser at redhat dot com>]

I just would like to add my 2cents to a few of Jim's remarks:

Jim Ingham wrote:
> 
> Daniel,
> 
> >> I understand that there is some argument over whether the current
> >> implementation of C++ symbol lookup is the right one, but while it is in
> >> place, simple fixes to it need to get into the sources quickly.
> >
> > I'd happily check them in under an obvious bugfix rule, but I don't want
> > to step on any toes.
> > I had enough fun doing that trying to figure out what exact areas of code
> > C++ maintainer covers, and I still couldn't tell you.
> > If someone with definite maintainership over the symbol tables says I can
> > check in the fixes, i'll do it. Otherwise, i won't.
> > Sorry.
> 
> I sympathize, but in this case the fix really is trivial...  This one really
> does fall under the obvious bugfix rule if any fix does...
> 

People were questioning earlier today if such rule really exists.
If it does not we are doomed.  Specially with the current maintainers
response
time (including me -- we all have our hands full).

We need a way to fix things quickly.  If it needs a better fix it should
be properly
documented so people get to it as soon as they can.

We cannot just leave things broken!!!

If this is an attempt to force volunteers to make extra work and do code
improvements
and cleanups is not working.  People are just giving up and leaving
things broken.
They are probably adding the fixes to their own copies and many other
developers/users
are suffering unnecessarily.


> >
> > Which explains why you keep mentioning users, when the bug only exists in
> > CVS.
> > This is a very bad idea to be doing.
> 
> I really don't understand this.  What else are we supposed to be basing our
> sources on?  There are two options here, apply patches from the Patches list
> in advance of their acceptance, or just stick with "official" releases (i.e.
> 5.0)
> 
> There are lots of good patches, and lots of bad ones, in the patches mailing
> list.  It is better, I think, for us to let the "experts" in the Maintainers
> group sort them out, and then use the results of this vetting process.  That
> IS what the whole Maintainer's (or Helpers??) structure is for.  Seems like
> subverting this process will just cause us more trouble.
> 
> On the other hand, does anyone think an unmodified 5.0 is a good release to
> base our efforts on?  It has been around for a while now, and has its own
> share of bugs that HAVE been fixed.  In any case, you don't really WANT most
> of your gdb users to stick with the 5.0 release, do you?  That would mean
> that the CVS changes are being tested by some set of Red Hat customers, and
> that is about all.  That would not be a very good idea.
> 

GDB 5.0 is so old and so broken (at least Insight is) that it is useless
to many
people.  If you look at the insight mailing list archives, people have
been forced
to download newer snapshots or even the CVS version because they just
can't use
the 5.0.

If we had created a way to have a set of patches to 5.0 available, or
even created
some updated 5.0 releases with just bug fixes (no new feature -- bug
fixes applied
to the old 5.0 code base) this situation could be better.  Even though,
there would
be things that the fixes would be to extensive to retrofit, and still
people
would have to resort to newer sources.

And developers also waste many hours because of known bugs with minor
fixes that just
werent comitted.

No matter how I look at it I can't find a good reason to leave bugs
laying around
when a fix is known.

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9