This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Beyond GCC 3.0: Summing Up
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: Beyond GCC 3.0: Summing Up
- From: Justin Guyett <jfg at sonicity dot com>
- Date: Tue, 10 Jul 2001 09:24:55 -0700 (PDT)
- Cc: Alexandre Oliva <aoliva at redhat dot com>,"dewar at gnat dot com" <dewar at gnat dot com>,"kenner at vlsi1 dot ultra dot nyu dot edu" <kenner at vlsi1 dot ultra dot nyu dot edu>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
On Tue, 10 Jul 2001, Mark Mitchell wrote:
> 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.
Any time a proper patch introduces a latent bug that's noticed and doesn't
affect any developers enough to get it fixed, but that is a regression
from the previous release, why not just mark it as "must be fixed" for the
next release, rather than backing it out? *Users* who are using gcc cvs
imho (as a user) shouldn't really expect everything to work perfectly
compared with the prior release. If gcc developers are stalled because
something they're working on depends on having the latent bug fixed, that
puts pressure on the maintainer and everyone else to fix the bug, which
ime always results in the bug being resolved much more quickly. In the
mean time, unless the stallee is working on something closely related to
the original patch/latent bug (in which case [s]he is likely to be able to
either workaround the latent bug or fix it), using a several-day-old
checkout should work, and maintains pressure on getting the latent bug
fixed.
You mentioned that you don't think it's easy to get latent bugs fixed
after they're exposed. Why is it easier to get them fixed 1) before
they're exposed and 2) when nobody really has any incentive because
nothing's broken yet ? Even if someone adds a regression test expecting
failure, how high priority is that? It still could be months (years?)
before that latent bug is fixed. How many XFAILs occur in x86 with
3.0.1-cvs? How long ago were they added?
justin