Re: [Gzz] [Fwd: Bug report]

[Hermanni Hyytiälä]

On Mon, 2003-06-30 at 13:06, Tuomas Lukka wrote:
> On Mon, Jun 30, 2003 at 12:54:12PM +0300, Hermanni Hyytiälä wrote:
> > > Umm - a comment about your bugreport: you should really narrow it down
> > > to a really short java program that you can send them, i.e. 10 lines of 
> > > java, showing that on SUN's jdk it produces output XYZ and on kaffe, 
> > > output FOO
> > > and that FOO is wrong according to the docs.
> > 
> > IMO, partly true. I really wanted describe how&when&why the bug was
> > discovered. I think adding 10 lines of simple java code is *optional*
> > (not mandatory) in the bug report since the authors of code can *verify*
> > the bug report's result by coding those 10 lines easily.
> > 
> > I think that how&when&why concept is more important in a bug report than
> > 10 lines of code representing a wrong functionality. But, OTOH, 10 lines
> > can be included if one wants so ;).
> 
> I disagree completely. This is an arrogant attitude which I really wish
> people who send me bug reports didn't take.
> 
> Here's again the numbers stuff: if the developers get 100 bug reports
> a day, do you think they prefer to read through the short story of discovery
> or just fix it?
> 
> Most bug reports are false. If the authors had to code 10 lines for each bug 
> report
> to make sure that it's true, or install large packages to test it &c, then
> it would just not be feasible - they'd spend all their time doing that.

I don't see anything wrong in this. I think that one important role of a
developer is also to *serve* end users among *developing* the software;
doing software is not only *developing* software, it's also fulfilling
end users' different needs (e.g. by fixing bugs/verifying if something
is a bug). And I think this the *responsibility* what a developer (the
*author* of software) takes when she/he releases a software, whether its
open source or non-open source software.

And what is important that and end user may be also a developer.

> 
> Doing the 10 lines is very little work for you, because you now know what
> it's about but for them it's much more since they have to start thinking 
> about this --
> while not even being sure whether you found a bug or have just misunderstood 
> this.

> Basically, if I get a bug report, I'd like to see
> 
> 1) what the bug is
> 2) why it is a bug
> 3) example code so that I can *duplicate* the bug easily on my 
> machine/environment
>    or see that my later changes have already fixed it
> 4) exact configuration
> 5) (optional but strongly encouraged) What this bug affects - your internal 
> code / 
>    some important package &c
> 6) (optional) potential fix
> 
> Adding the java code is optional only if you cannot, for some reason, 
> make that code (i.e. you haven't found a short program that duplicates
> the problem or you are not a coder).

Ok, in my case, the 10 lines of code would be feasible since I *can*
code (i.e. I'm (also) a developer). So I agree this in my case. 

But in case of a regular end user/beginner programmer (as you mention
it), it is almost always impossible to create a simple source code which
would reveal the bug. Also, many end users (even in open source
community) are not able to do a "complete" bug reports since they don't
necessiraly know even their *exact* configuration, to say nothing of 5)
and 6).

Finally, there seems to be clear difference between non-open source
community and open source community with bug reporting in general ;).
While in non-open source community people sends only "this does not
work" messages with *automatically generated* configuration reports, in
open source community it is expected that (almost) all end users are
also developers &c: when making a bug report it is assumed that you
would provide "complete" bug report (even) containing a potential fix.

But hey, isn't this the thing why open source software do exist ? ;)


-Hermanni