Re: Beyond GCC 3.0: Summing Up

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    I think the core of your argument is that causing a "latent" bug to
    become an actual bug is good because then we will try to fix it.  

>From my perspective, I don't see that as the major issue per se.  I see
two things:

(1) It's simply easier to work on fixing something when you can see it
in top-of-tree sources.

(2) The person best suited to work on the latent bug is often not the
same as the person who did the original patch.  For people like most
of those involved in this discussion, there's no major issue unless
the latent bug is in some particularly obscure part of the compiler,
since we can work in most of the compiler.  But requiring somebody to
be able to do that before we'll accept a patch is a very high bar for
somebody to have to meet in order to contribute to the project.

    But, this latent bug thing is really a side-issue.  If it's that big a
    deal, we can compromise.  The important thing is that the typical
    broken check-in (which does not expose a latent bug, but is just plain
    buggy itself) must either be fixed or reverted.  

I have heard nobody argue against that.  Clearly if a patch itself is
broken, it can't stay in very long unless it's fixed.  I, and some
others, have argued over precisely what "very long" means and what, if
anything, that length of time is a function of, but I think the above
is generally well-accepted in principle.

The far trickier issue is latent bugs and, for me, the main reason is
that the knowlege needed to fix it is usually very different from that
needed for the original patch and it isn't reasonable to require
contributors to have that knowlege.