Re: Small update to reversed_comparison_code

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Richard> Yes, but nothing could have prevented that since it looks
    Richard> like it's a latent bug in reload_cse which gets triggered
    Richard> at random by changes, in this case by code that isn't
    Richard> even executed during the bootstrap (RTH's change to
    Richard> 64-bit support).

    Richard> What you are proposing is indeed a worthwhile goal, but I
    Richard> just don't think it's very realistic given the type of
    Richard> problems that occur in practice.

I disagree.

It wasn't the content of Richard's changes that caused the problem --
but it was still Richard's changes.  Suppose that we had an automated
system.  At that point, we would have *known* there was a problem.
And, we could still have made progress fixing other bugs using Solaris
boxes.

We just traded away N days * K developers for the convenience of
avoiding Richard having to save the patch away in a file of "do this
as soon as Solaris gets fixed".

Richard (or someone else) could have tracked down the problem *before*
the patch went in, thereby allowing everyone else to make progress.

In this particular case, Richard is doubly not to blame because the
problem only occurs with --disable-checking, which was not the default
configuration on the branch when Richard checked in his patch.  So,
I'm certainly not blaming Richard!

However, you are essentially arguing that if a patch tickles a latent
bug, then it should go in anyway -- to incentivize people to fix the
bug.  That discounts the cost to the organization as a whole of not
being able to build anything.  It also enables double faults --
situations where new broken patches go in, but nobody can tell because
it was already broken before.

The right solution is to hold on to the patch, and figure out the
latent bug.  The person contributing the patch can do that, or they
can explain the problem to someone else so that the someone else can
fix the problem.  The person who wants the original patch checked in
is incentivized to get the latent bug fixed.

To use a market analogy, people must pay the cost (to others) of their
changes.  That is the only way to incentivize people not to make
check-ins that break things for everyone else.

More concretely, if we cannot agree on policies that keep the tree
working on major platforms most of the time, we are simply
incentivizing interesting parties to fork, and work on their own
stable development branches.  No organization, commercial or
otherwise, wants to commit resources to fixing other people's bugs
as often as has been necessary recently.   

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com