Re: Small update to reversed_comparison_code

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

    If Richard (and again we're fully hypothetical here) didn't care
    enough to figure out what's really wrong or to persuade anyone else to
    do so, then should the patch go in?

Yes, because that patch fixed an unrelated bug.

Why should the fixer of that bug (to say nothing of the person
*reporting* that bug) be penalized because of a totally random
triggering of a completely unrelated bug elsewhere?

    Are you saying that the Solaris maintainer should have done this?  (It
    wasn't a Solaris problem.)  The cse maintainer?  (There was no way to
    know it was a CSE problem.)  The release manager?  (Who failed to
    detect the root cause of the problem, through no particular fault of
    his own.)

I understand that there's no way to "assign" this to somebody, but in the
long term, getting that latent bug fixed is important to the project.

    In pratice, the bug sat unfixed for weeks, which indicates that the
    current system didn't incentivize anyone to fix the bug in an
    efficient way.

True, but how long do you think the latent bug would have taken to get fixed
if the patch had immediately been removed from the branch?  I'd guess far
longer, if ever (and probably never).

    None of us are entitled to take the arrogant attitude that our
    check-ins our more important thatn anyone else's.  Saying "I checked
    this in, even though it breaks Alpha, because the Alpha back-end is
    broken" is, quite simply, rude.

I agree with that.  But that's the case where somebody knows beforehand that
they are breaking something, which isn't normally the situation.

    Ironically, my understanding is that ACT already uses a system like
    this internally.

Yes, ACT has something like this, but the major difference is that most
patches sent through it are to the front end and machine-dependent bugs or
bootstrap failures are rare.  That mechanism flags regression tests that fail
with a patch.  So it's easy for the patch submitter to see what went wrong.

There are a few cases where regressions *are* system-specific.  In those
cases, if they are critical systems, either the patch is removed or the
problem (often a latent bug elsewhere) is fixed.  But there have been a
number of failures in less critical systems that have been deemed less
important than the fix.

    Part of your argument is that people don't know about all these
    issues.  But that means, quite frankly, that they shouldn't be working
    on parts of the code where these issues matter -- or that they need
    careful supervision/support from more experience people.  

Not true in the case of triggering latent bugs.  Look at RTH's patch, the one
we've been discussing.  It was a fix to an obscure bug in the way structures
are returned in the 64-bit Sparc ABI.  It's reasonable for somebody working
in that area to understand the relevant ABI and the config files in question.
But do we *really* want to say that understanding the intricacies of
reload_cse is a prerequisite to fixing a bug in structure returning for Sparc?