Bug backlog - now and future. Some proposals.

[James Kosin]

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