This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 4.0 Status Report (2004-01-05)


Gabriel Dos Reis wrote:
Robert Dewar <dewar@adacore.com> writes:

| don't know about. For a user hitting the bug, it does not make much difference.
| So it is not terrible to issue software with known bugs, since you are going
| to issue it with unknown bugs in any case


That reasoning is specious.  Documenting a bug as known saves us
from receiving deluge of duplicate bug reports and save users hours of
arrassements.  Unless, of course, you don't care about bug reports or
don't encourage users to report bugs.  Do you spend hours per day, as
does Giovanni, trying bug reports in our bugzilla database?

Sorry, I guess I was not clear, yes, of course it is desirable to document bugs as known, that's definitely worth while. What I was saying is that there is no imperative to *fix* all known bugs before a release, and yes, of course trying to fix bugs is a critical activity.

The important point is that it is not terrible to release a product
with known bugs. Sometimes, people get into the mode that they do
think this is terrible, since in a quest for perfection they want
a bug free product. Well everyone wants a bug free product, but there
is nothing very special about releasing on a day when you don't
*know* about any bugs.

I will say from our experience of documenting bugs in GNAT Pro that
for many bugs it is not so easy for users to tell that they have or
have not hit a duplicate bug, and we generally don't encourage users
to spend a lot of time trying to figure out if their problem is already
known and fixed in a future version. That's particularly true of
e.g. optimization bugs. However in
our (AdaCore) case, these users are paying customers, and we don't
regard it as "arrassment" for them to ask questions :-) On the other
hand for users of freely available software, it seems quite reasonable
to ask that as part of their contribution to the volunteer effort that
they not only submit bug reports, but that they do invest the time to
make these reports as thorough as possible, and to carefully check the
documented open bugs. In fact ideally, in this environment, the bug
reports act as a first level documentation. In the GCC community we
don't find it very useful for people to send large programs with a
note saying "this doesn't work, why not?" [whereas in the GNAT Pro
commercial support environment, that's much more reasonable, it is
the kind of thing that people pay for -- of course there is sometimes
still not much we can do if a user dumps a million lines of complex
avionics code on us and says "why doesn't this work" :-)]

Since the GCC developer community does indeed ask people to
take the trouble to make detailed bug reports,
it is indeed the case that it is highly desirable to document
existing bugs as well as possible.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]