Bug backlog - now and future. Some proposals.

[max bianco]

On Mon, Mar 17, 2008 at 12:20 PM, James Kosin <jkosin at beta.intcomgrp.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> max bianco wrote:
> |
> |     << SNIP >>
>
> |     |
> |     | +1, to a point.
> |     |
> |     | If the "maintainer" has (reasonably) asked for more information
> and it
> |     has been 1 release with no more information coming in, _then_ it
> would
> |     be reasonable to close the bug.
> |     |
> |     |
> |     But, iff the release addressed an issue related to the bug report
> in the
> |     first place.  Closing a bug just because you don't have any more
> |     complaints is not really a valid reason.
> |
> |
> | How long should it be kept open if no more information is forthcoming?
> |
> |
> |
> |     Maybe part of the release process should be to recreate the
> problem and
> |     be able to prove the problem is fixed by testing!
> |
> |
> | How do you know the bug is real? The person reporting the bug needs to
> provide enough information to reproduce the issue. What is essential info?
> | I think a bug reporting tool that is integrated into the desktop
> itself is going to be required here. The tool could walk a user through
> the bug reporting process and maybe insure that appropriate logs are
> attached by default, at least we need to ensure that enough info is
> provided to reproduce the problem. Sometimes people report as bugs
> things that are not bugs and alot of time gets wasted.  If we want  all
> bugs fixed in a timely manner then we have to provide  the developers
> the  means to do so and i think that means some sort of integrated bug
> reporting tool that  ensures that a minimum amount of info is provided
> for them. How many times has someone cursed the application only to find
> that they overlooked something simple? Everyone has their own custom
> setup and that can make reproducing a problem difficult.
> |
> |
> | Max
> |
>
> Max,
>
> I was commenting on the assumption it was a valid BUG.  It is difficult
> if not impossible to catch everything.  If a bug is or does not contain
> enough information then it really isn't a bug yet.
>
> I agree we need a better method to capture the problem and provide
> enough information to reproduce the problem elsewhere, but whose
> responsibility is that.  The bug reporter often either knows very little
> of the problem or has caused the problem himself in most cases; but,
> some are caused by others....  selinux security settings for example,
> and when fixed sometimes ILL documented in the release notes.
> At the same time, the user needs to keep on top of his/her bugs and
> update them as needed.  Just ignoring a bug can lead to BAD things for
> both parties.  The user in that the problem may not be fixed (causing
> issues for others in the future) or worse still the maintainer not
> knowing what the true bug status is.
>
> At the same time, we shouldn't take bug reports lightly.  They are
> difficult enough for users to write up properly, so anyone taking the
> time to actually write one up should be looked at carefully.
>
> Some standard questions should be (1) post configuration files, (2) post
> any pertinent log files, (3) core dumps if available.
> At the same time, the maintainer needs to be able to provide the user a
> way to DEBUG the issue.  Not everyone is experienced in the debugger
> tools or how to get a trace, or dump of any core files.
>
>
I think we agree on the major points. It is precisely because not everyone
is an experienced debugger that I think some sort of integrated tool is
required. An integrated tool that would default to attaching appropriate log
info is essential. Better to much info than not enough. How many will tell
on themselves if they figure out it was their fault? Not many! Most will
never report back, in which case you have a bug report floating around that
can never be resolved because it was never a bug to begin with....or due to
inexperience on the users part it takes forever to get the required
information.  So some kind of bug reporting\ debugging tool is needed. I
don't think you will find many objections to the idea in theory but the rub
will be in how it gets implemented.

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20080317/a9f5ecd3/attachment-0001.htm>