| Summary: | Do you really do not need crash reports where the user can not give information? | ||
|---|---|---|---|
| Product: | [Applications] drkonqi | Reporter: | m.wege |
| Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | wishlist | CC: | andresbajotierra, sitter |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
m.wege
2010-01-24 15:49:13 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 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. 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
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. |