Re: Bug backlog - now and future. Some proposals.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux