| Summary: | allow drkonqi to merge bug report directly into existing bugs | ||
|---|---|---|---|
| Product: | [Applications] drkonqi | Reporter: | Darin McBride <Tanktalus> |
| Component: | general | Assignee: | Dario Andres <andresbajotierra> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Unspecified | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Darin McBride
2009-07-16 18:44:08 UTC
Hi. Yes, we have this idea in our ToDo. However it will need some checks before implementing it, because we need to avoid mixed reports with different backtraces on it. (novice users could misuse this "This IS a dupe of X bug" option) And may be there is no proper way to check if two backtraces are related (specially if one of them is incomplete). So we could try to check for the original reporter, product, or some words at the problem description. Do you think of any other idea on how to solve this issue? Regards You might just be overanalysing the issues. Today, there is nothing to stop me from pasting backtraces to the bugzilla website that are unrelated to the bugs I'm responding to. I could put 8000-line backtraces on every single open bug if I were bored (and malicious and stupid). I could pipe backtraces through rot-13 (three times, even!) before pasting them. There's all manner of crazy I can do with a login ID. Adding this feature doesn't add to it. Merely makes it convenient to do once. Novice users can abuse bugzilla. Always could, still can, probably always will be able to. Checking for the original reporter doesn't seem to do much - I probably am not the original reporter when I find the duplicate bug. Or maybe I went and installed the debug libraries so I have a more complete bug report now for a bug I already reported and have reproduced to get a better stack trace. If you find someone is simply not trustworthy for this, you could have an entry on bugzilla (or elsewhere) that tells DrKonqi to disable the option once they're logged in. But even that is just a hack - I can always go in and patch DrKonqi to remove that if I'm malicious enough. (You'd have to have that logic on the server somehow, but I don't think that'll be easy to do when I have access to the DrKonqi source code.) I'm not talking about being malicious, but unexperienced. I mean, most of the people doesn't know how to identify/read/comprehend backtraces, so it could be difficult for them to check "duplicates" just looking at backtraces. (situation could be similar, but BTs could be different, and the source of the crash could be different too) Bugzilla wizard encourages the user to check for duplicates and write on them instead of opening new reports (even for crash, which could mean mixing backtraces) (btw, there is a bug report against bugzilla to improve this behaviour). The new crash handler tries to avoid that always opening a new one. (and it allow the user to check the possible duplicates to help the bug triagers later). The reporter can always mark their own report as duplicate of another one (using the bugzilla interface). Actually the item in my ToDo list was "attach new info to an existing report" (that would mean that the reporters need to be the same person / match). May be adding some option to actually mark as duplicate/attach to an existing report but with some confirmation messagebox or something. Regards I added this on 4.4, in a way that will not mixup (possible)different reports. All the new information is added as an attachment, so that will not affect backtrace searches in bugzilla in case the backtraces are different. I also added some warnings about attaching. (reporter should be sure it is the same crash) Regards |