The art of closing bug reports

The art of closing bug reports

[Lennart Borgman]

I am a bit disturbed by bug reports that are closed without much
effort trying to understand if the bugs are still there. Is this
really the best way to get Emacs into a more bug free state?

Re: The art of closing bug reports

[Juanma Barranquero]

> I am a bit disturbed by bug reports that are closed without much
> effort trying to understand if the bugs are still there.

Such as?

    Juanma

Re: The art of closing bug reports

[Lennart Borgman]

On Sun, Jul 10, 2011 at 02:52, Juanma Barranquero <lekktu@gmail.com> wrote:
>> I am a bit disturbed by bug reports that are closed without much
>> effort trying to understand if the bugs are still there.
>
> Such as?

I do not think that question is serious. That is my experience from
before. Can you explain how saying these words will help the
development of free software?

Re: The art of closing bug reports

[Glenn Morris]

>> I am a bit disturbed by bug reports that are closed without much
>> effort trying to understand if the bugs are still there.

There is also an "art" to opening bug reports. It's well documented, and
many people manage to do it. I'm sorry to say, but some bug reports are
of such low quality that they essentially have no value. Leaving them
open does nothing except dilute attention away from other reports where
progress can be made.

Re: The art of closing bug reports

[Lennart Borgman]

On Sun, Jul 10, 2011 at 03:02, Glenn Morris <rgm@gnu.org> wrote:
>
>>> I am a bit disturbed by bug reports that are closed without much
>>> effort trying to understand if the bugs are still there.
>
> There is also an "art" to opening bug reports. It's well documented, and
> many people manage to do it. I'm sorry to say, but some bug reports are
> of such low quality that they essentially have no value. Leaving them
> open does nothing except dilute attention away from other reports where
> progress can be made.

Since I happen to manage many bug reports myself I have some
experience with this. I close bug reports that I can't reproduce and
get no feedback on. But I do not do that if I just do not have time to
reproduce them. Then I just leave them since they might be valuable
further on.

Re: The art of closing bug reports

[Juanma Barranquero]

On Sun, Jul 10, 2011 at 02:56, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> I do not think that question is serious. That is my experience from
> before. Can you explain how saying these words will help the
> development of free software?

I'll do, as soon as you explain to me how do help the development of
free software (or just Emacs) bugs that say "I have this crash, for
which I won't send a recipe because I'm a very busy guy, which perhaps
happens because of my local modifications (that, by the way, I have
sent you *hundred of times* and you refuse to include into Emacs just
to make my life more difficult) and perhaps not, because I don't
really remember, which happened so long ago that I don't even remember
what was I doing at the time or how to reproduce it... and please
don't ask me for clarification or help in reproduce it, because, as I
said, I'm a very busy guy, so please do all the work yourselves and,
by the way, what's not clear in my report?"

If you think I'm being harsh or mocking you, you need to distance
yourself from your own bug reports and try to read them as they are,
not as they seem to be in your imagination.

    Juanma

Re: The art of closing bug reports

[Lennart Borgman]

On Sun, Jul 10, 2011 at 03:31, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Sun, Jul 10, 2011 at 02:56, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> I do not think that question is serious. That is my experience from
>> before. Can you explain how saying these words will help the
>> development of free software?
>
> I'll do, as soon as you explain to me how do help the development of
> free software (or just Emacs) bugs that say "I have this crash, for
> which I won't send a recipe because I'm a very busy guy, which perhaps
> happens because of my local modifications (that, by the way, I have
> sent you *hundred of times* and you refuse to include into Emacs just
> to make my life more difficult) and perhaps not, because I don't
> really remember, which happened so long ago that I don't even remember
> what was I doing at the time or how to reproduce it... and please
> don't ask me for clarification or help in reproduce it, because, as I
> said, I'm a very busy guy, so please do all the work yourselves and,
> by the way, what's not clear in my report?"
>
> If you think I'm being harsh or mocking you, you need to distance
> yourself from your own bug reports and try to read them as they are,
> not as they seem to be in your imagination.

Not at all, Juanma. This is just exactly to the point.

Re: The art of closing bug reports

[Tim Cross]

On Sun, Jul 10, 2011 at 12:03 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Sun, Jul 10, 2011 at 03:31, Juanma Barranquero <lekktu@gmail.com> wrote:
>> On Sun, Jul 10, 2011 at 02:56, Lennart Borgman
>> <lennart.borgman@gmail.com> wrote:
>>
>>> I do not think that question is serious. That is my experience from
>>> before. Can you explain how saying these words will help the
>>> development of free software?
>>
>> I'll do, as soon as you explain to me how do help the development of
>> free software (or just Emacs) bugs that say "I have this crash, for
>> which I won't send a recipe because I'm a very busy guy, which perhaps
>> happens because of my local modifications (that, by the way, I have
>> sent you *hundred of times* and you refuse to include into Emacs just
>> to make my life more difficult) and perhaps not, because I don't
>> really remember, which happened so long ago that I don't even remember
>> what was I doing at the time or how to reproduce it... and please
>> don't ask me for clarification or help in reproduce it, because, as I
>> said, I'm a very busy guy, so please do all the work yourselves and,
>> by the way, what's not clear in my report?"
>>
>> If you think I'm being harsh or mocking you, you need to distance
>> yourself from your own bug reports and try to read them as they are,
>> not as they seem to be in your imagination.
>
> Not at all, Juanma. This is just exactly to the point.
>
>

Two concrete ways I think closing of bug reports could be improved are

1. Include the full bug report subject and not just the bug number in
the closure notification. I regularly see closure notices that only
include the bug number and a message which often just says the bug has
been closed.

The problem with this is that it gives no clue as to which bug it was.
We tend not to remember bug report numbers, but often will recognise
subject or description. Knowing that a particular bug (and I'm talking
about ones that you have not lodged yourself) has been closed can be
very useful.

2. Include a tag in the closure message which indicates whether the
bug was closed because it is believed to be fixed, cannot be fixed,
cannot be reproduced, is a duplicate of another bug etc.

Both of these suggestions are mainly relevant to those who monitor the
email list or newsgroup. I am assuming that if you use the bug tracker
directly, then this information is already there.

I guess the lack of details in the closure messages is possible a
reflection of lack of time or possibly a limitation with the bug
tracker mail/news gateway. However, many bug tracking systems I have
used have some sort of templating system and perhaps all that is
needed is some tweaking of these templates.

Tim

Re: The art of closing bug reports

[Bastien]

Hi Lennart,

can you give an *example* of a bug report that have been closed 
the wrong way?  Otherwise this discussion will remain too general.

Thanks,

-- 
 Bastien

RE: The art of closing bug reports

[Drew Adams]

> 1. Include the full bug report subject and not just the bug number in
> the closure notification. I regularly see closure notices that only
> include the bug number and a message which often just says the bug has
> been closed.

1+

But since this is variable, I've been assuming (?) that this was due to the way
some particular bug subjects were created in the first place (e.g. perhaps older
bugs).  It seems that some have `#9999' in the subject, some have just `9999',
some have the complete subject.

It is good to have both the subject and `#999' - easiest to run a search.  If
the bug number were in fact quoted (in future), then a search would be easier
still.  For example, searching for "`#999'" gives no false positives such as
searching for "999" or "#999" can ("#999" as prefix or "999" as substring).
(I'm assuming a literal, not a regexp search, which is the case for at least
some mail clients.

Yes, this is a nit.  Just something we might consider, if other things are
equal.

> The problem with this is that it gives no clue as to which bug it was.
> We tend not to remember bug report numbers, but often will recognise
> subject or description. Knowing that a particular bug (and I'm talking
> about ones that you have not lodged yourself) has been closed can be
> very useful.