Re: [Gzz] [Fwd: Bug report]

[Tuomas Lukka]

On Mon, Jun 30, 2003 at 01:40:46PM +0300, Hermanni Hyytiälä wrote:
> 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. 

Really?  I'm astonished.

> 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). 

This would be the right attitude if the developers were really working
for you and you were paying them money.

However, this is not the case.

Here, the deal is

        - they put out free software
        - they are often also willing to fix bugs

If your side is

        "I don't want to bother to write a test case - I'll just
        send them some notes about how I found a bug and some notes
        about what the bug itself is"

then the deal is a little off balance, right?

The correct and, most of all, **polite** way is

        "Hmm, I've found a bug - what can I do to make it easiest
        for them to fix it within reason?"

Within reason: If you're not familiar with the code, you don't need to write
an actual patch, but if you're a coder, a reproducible test case if
of very little bother to you and of enormous value to the person
receiving the report.

There are free software projects that have ENDED because people sent in
vague and bad bug reports and the developers got tired of doing the project --
very understandably.

> 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.

No. You can't go on assigning other people responsibilities.

If they are willing, out of their own goodwill, continue development
and fix bugs, you should be grateful to them and make their life easier.

You're forgetting the cardinal rule of RFC:s:

        be strict in what you produce, and liberal in what you accept

It's right to *feel* the responsibility and act accordingly. It's NOT RIGHT
to *EXPECT* it from others about whose situation you have no knowledge.

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

? How is this relevant?


> > 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. 

Indeed.

> 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. 

Naturally. In their case, the "source code" is instructions on how to exactly
reproduce 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).

Yes, and as I say above, it's all "within reason". If it's not within
reason to get some info, then it can be left out. 

The point is: if it's not a lot harder for you than for the developer then
you should do it.

> 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 ? ;)

Yes. Exactly. For closed software I've paid for it and have a right to expect
that it works! In open software I get it for free, in exchange for good 
behaviour
and participation.

        Tuomas