-----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.
James
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH3ppXkNLDmnu1kSkRAiPSAJoD60hsrw7eQkI+8x8SDmDpEvFrEACdFwtY
C5lH67qb608RYOwl3EMEcv4=
=nMrK
-----END PGP SIGNATURE-----
--
Scanned by ClamAV - http://www.clamav.net
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
