Re: Small update to reversed_comparison_code

[Mark Mitchell <mark at codesourcery dot com>]

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

    Richard> I shouldn't speak for him, but I believe the patch in
    Richard> question was a minor one that likely didn't involve much
    Richard> work.  *Far* more work (perhaps by 2-3 orders of
    Richard> magnitude) have gone into dealing with the totally
    Richard> unrelated latent bug his patch triggered.

So?

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?

Why did you think someone else should care more than the person with
the offending patch?  In this case, much of the effort was going to go
into the detection of the bug.  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.)

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.

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.  If someone wants to do such a thing,
they should ask for SC approval first.  There are cases where it makes
sense -- but they should be rare.

*If* we could arrange automated pre-commit testing on x86 GNU/Linux,
MIPS IRIX, PPC AIX, SPARC Solaris, Alpha TRU64 and PA HPUX we would
find many, many bugs before everyone else sufferred through them.
That hits most of the most popular chips, and most of the most popular
operating systems.  Add in an embedded target (ARM GNU/Linux, or PPC
RTEMS) and we'd hit even more.  Pick only three of these and you'd
still eliminate probably 50% of the problems that we see now.

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

In that bunch, we have ELF, COFF, DWARF, Stabs, weak symbols, no weak
symbols, different shared library semantics, and lots more.  Sure, the
odd BSD bug would slip through -- but most developers would have a
working tree most of the time.

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.  It's lack of
awareness of these issues that have lead to designs/implementations
that do not work across these platforms.  (Assumptions about
shared-library initialization order and weak symbol support come to
mind.)

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