Re: Beyond GCC 3.0: Summing Up

[Mark Mitchell <mark at codesourcery dot com>]

>> Why not simply revert the patch, and/or put it on a branch, so that
>> people can work on fixing the latent bug without interfering with
>> everyone else?
>
> Because reverting the patch will also introduce a regression, and
> reverting the patch has a strong potential of having the bug (and the
> fix) end up forgotten, so we'd remain with two bugs, instead of one.

Clearly, you and I don't see these issues the same way.  I'm very
disturbed, because often you and Bernd and I see things the same
way, approximately.  I'm even more disturbed because Robert Dewar
*does* agree with me, and he and I normally see things the same
way too.

I wonder if there is some difference between people who manage companies
and normal people; perhaps Robert and I are in some weird pointy-haired
boss mode here.

I think I can only conclude that you have a much greater confidence
in our ability to solve problems after the fact than I.  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.  And if we
don't bother, then it wasn't a very important bug.  Of course,
that means it wasn't a very important bug *to us*, not to our users,
but since this is free software, perhaps you are assuming that if the
users care they will find the bug and arrange to have it fixed before
the release.

I just don't have this religion.

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.  We can then have regular
flamewars about whether or not a bug was latent.

Do you object in the normal case, or just the "latent" case?

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