This is the mail archive of the
mailing list for the GCC project.
Re: Fixing Bugs (Was: A Suggestion for Release Testing)
chris jefferson wrote:
> One thing I have come across, both in gcc and in other projects, is that
> often discussion is not the best option, but instead just writing some
> code is better.
There's a fine line between too much talk and not enough.
> It's very easy to have discussions go around in circles about if option
> a or option b is better, and which will lead to slowdowns, or intrusive
> changes, or whatever.
I'm more interested in "Does doing A make any sense?"
An example: In its formative stages, gfortran had a problem with certain
kinds of constants. Whether the problem needed to be solved depending on
how strictly one read the standard.
I simply went ahead and wrote a patch (actually, three of them), trying
to satisfy all sides involved. This resulted in long discussions of
whether the problem really *was* a problem or not. In the end, the
compiler was modified to behave as other Fortran 95s do (which was my
original suggestion, before people started quoting the standard), and I
wasted much of the time spent writing the original patch.
Had the problem been talked out in the beginning, I could have spent
more time working on an acceptable solution. This is one incident that
lead me to stop submitting patches; I have only so much time for GCC,
and am donating all of it out of my own pocket. Maybe others can afford
to do that, but I can't, after three months in the hospital followed by
an injury to my wife. If I'm going to contribute to GCC, it needs to be
something I know will be more than just a shot in the dark.
> While it's briefly annoying to write code which then isn't used
> the first time you do it, I've quickly learned it's faster and easier
> than extensive discussions, and most good code will go through 3 or 4
> iterations before it finally settles, and need a whole bundle of tests
> writing, so writing an initial test version is not actually that big a
> time investment compared to the total amount of time something will
> take. Working code is also of course by far the most convincing argument
Perhaps I'm too steeped in being an engineer, but in my experience,
quality upfront discussion saves a lot of time and produces better
results. I'd hate to build a bridge the way you suggest developing GCC.