nepomukservile just crashed on me and the "crash report" dialog sprang up. Ok, so far, so good. I happen to be running an unstable Gentoo so I've got 4.10 (*not* GIT head, but 4.10 isn't in the menu above!) I also run a complete debug system - full debug info (PDB in MS terms) on every single thing on the system. So I know the crash was in side clock_gettime from the backtrace. This certainly looks like useful information (I suspect I could debug the crash in about half an hour) but you guys aren't getting it because the automagic crash report made me say WTF, it's your problem, within 30 seconds. Here are the problems: 1) The information isn't simply filed somewhere for later analyse, it's used (apparently) to generate a full-fledged bug report. I guess you don't expect many users to use it. However; 2) The report requires a log in. I happen to have one, of course I can't remember either the user id or the password, so I'm not very likely to do anything other than cancel the whole process, but I did actually go to the trouble of rediscovering it, and logging in (this had already taken too long), whereupon; 3) You present me with a whole load of bug reports which I'm meant to review (I guess nepomukservices crashes a whole load of times.) Gee. There's a symbol in there at the top of the stack but; 4) Guess what, I'm not doing that. If I had that amount of time to spend I'd simply debug the crash myself. In other words it would take me longer to *report* the bug than to fix it. John Bowler <jbowler@acm.org>
You can use the KDE Wallet to store the login data, so on next bug report, you do not have to re-enter the login data. Login is required to contact the bug reporter. Automatic detection of duplicates is only a blind guess, and requires human checking, so if you have no time to check the duplicates, simply report it anyway, and let the bug triaging team check the duplicates. Reading carefully, what you wrote does not sound like a bug report, nor can I see what you suggest to improve the situation.
(In reply to comment #0) > 1) The information isn't simply filed somewhere for later analyse, it's used > (apparently) to generate a full-fledged bug report. I guess you don't > expect many users to use it. However; I don't know whether that expectation is right , but *the reality* is many users use DrKonqi to report crashes. From 2012-01-01 to now, bugs.kde.org receives about 9K crash reports from users through DrKonqi. bugs.kde.org never worries about not receiving enough crash reports. Never. > 2) The report requires a log in. I happen to have one, of course I can't > remember either the user id or the password, so I'm not very likely to do > anything other than cancel the whole process, but I did actually go to the > trouble of rediscovering it, and logging in (this had already taken too > long), whereupon; Bugzilla itself (used by bugs.kde.org) requires registered account and login. That will not change until bugs.kde.org uses a different bug tracker or DrKonqi doesn't forward crashes to bugs.kde.org anymore. Neither are likely to happen in the near future. > 3) You present me with a whole load of bug reports which I'm meant to review > (I guess nepomukservices crashes a whole load of times.) Gee. There's a > symbol in there at the top of the stack but; You don't have to . > 4) Guess what, I'm not doing that. If I had that amount of time to spend > I'd simply debug the crash myself. In other words it would take me longer > to *report* the bug than to fix it. Fair enough. Nobody forces you to report it. Actually, the very first dialog of DrKonqi says it clearly " It is safe to close this dialog if you do not want to report this bug " And after you fix it, do not forget to submit a patch at reviewboard.kde.org