Bug 224049 - Do you really do not need crash reports where the user can not give information?
Summary: Do you really do not need crash reports where the user can not give information?
Status: RESOLVED NOT A BUG
Alias: None
Product: drkonqi
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-24 15:49 UTC by m.wege
Modified: 2021-06-21 00:43 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description m.wege 2010-01-24 15:49:13 UTC
Version:           Unbekannt (using 4.3.95 (KDE 4.3.95 (KDE 4.4 RC2)), Kubuntu packages)
Compiler:          cc
OS:                Linux (i686) release 2.6.31-18-generic

Dr. Konqui does not allow to report bugs where the user can not give additional information. I am not a programmer, but is the crash information really not useful? Those crashes which appear when I am doing nothing or nothing with the programm which crash can not be reported then. Also it could be the case that the user could answer questions which help to determine the bug. Depending on what you think it is useful, I would suggest to change either the questions of Dr. Konqui or the decision mechanism less rigid in deciding that a backtrace will be not usefull.
Comment 1 Dario Andres 2010-01-24 19:41:00 UTC
This is done this way because we currently lack the manpower to handle the amount of incoming reports, and ask more information on them later. So we suggest the user to try to add as much information as possible and to have a reasonable good backtrace (as we now included a way to automatically install the missing debug packages (hoping that distributions implement the feature)).

There are some special cases, when even a small description with no good backtrace could still be useful, but a program can determine that without implementing too much logic.

If we get more manpower I could try to lower the requirements of the bug reporting process.

On the other side, which kind of backtrace is considered not really useful ? (may be there is a bug in the parser, or the backtrace is indeed bad). 
(and a bad backtrace of a random crash is a no-no... sorry)
- Could you post an example ?

--

In KDE SC 4.4 we included a lot more of questions and examples to "estimulate" the reporter's memory/senses in order to get more info.
I was planning to add the same info in the Description step. (for KDE SC 4.5)

--

- What do you think about this ? Do you know of any other way for the decision logic to be less rigid; without requiring more manpower ?

Regards
Comment 2 m.wege 2010-01-24 20:10:49 UTC
I can not post an example, because I do not mean the case where the report is rejected because of a missing backtrace. I mean those questions asked. If I can reproduce the bug, if I can tell what I was doing or something special about the environment. If I say no to all this questions, the backtrace is just thrown away.
Comment 3 Dario Andres 2010-01-24 20:15:20 UTC
The context of the crash is required 95% of the times, in order to identify it. (even minor config details can be useful; those are included in the questions too). 

In KDE SC 4.3, in a lot of good reports, with good backtrace, I ended up asking for crash contexts on most of them. ("does the app crash again if you repeat the situation?" and so on)

Regards
Comment 4 Harald Sitter 2021-06-21 00:43:17 UTC
In 11 years nobody wanted to change this so I'm closing this wish. In the long run I hope we'll eventually gain a crash tracking system in addition to bug reports. In such a system we would record all crashes regardless of available context or trace quality so long as the user wants to send us whatever drkonqi was able to cobble together on its own.