Bugzilla – Full Text Bug Listing
| Summary: | [Duplicate Detection] Provide a way to compare stack trace of a new bug with the search results | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Tomasz Zarna <tomasz.zarna> |
| Component: | Mylyn | Assignee: | Project Inbox <mylyn-triaged> |
| Status: | CLOSED MOVED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P5 | Keywords: | helpwanted |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Tomasz Zarna
Sounds strange. If detector did found the duplicate stack trace, then there is really no point or compare. Is is an issue about trusting the duplicate detector results? What about a situation when the detector found more than one task? Is that possible? If not, I think there is always a possibility that the detector is wrong suggesting that there is a task for that given stack trace. With the compare editor I would be able to double check that (i.e. is this really a dupe), but only if I don't trust the duplicate detector. Tomasz, do you also double check results of the "Find Text" action in the text editors? :-) There is nothing wrong with finding more then one duplicate, for example if users who submitted those issues didn't bother to actually check for the duplicates. Consider that duplicate issues can have more then one stack trace in their description and comments. Search will find those, but I am having troubles to see how "compare stack traces" feature would allow to select the right stack trace and how it would look like in the UI. To clarify, I am not against of adding this feature, but just want to cover all the corner cases. (In reply to comment #3) > Tomasz, do you also double check results of the "Find Text" action in the text > editors? :-) :D What I meant is that stack traces are more complex than regular search phrases entered in the "Find Text". Especially when combined with "fuzzy searches" as mentioned in bug 198497. > Consider that duplicate issues can have more then one stack trace in their > description and comments. Search will find those, but I am having troubles to > see how "compare stack traces" feature would allow to select the right stack > trace and how it would look like in the UI. The compare editor I would like to provide wouldn't have to know about the fact that there is more than one stack trace. I would expect a stream that contains the stack trace. Mylyn specific support would need to extract the stream for the proper stack trace. I think it shouldn't be hard to find one when limited only to one bug report. Regarding the question about the UI, I was initially thinking about opening a compare dialog (with both content areas in read-only mode). But we could use regular compare editor too. > To clarify, I am not against of adding this feature, but just want to cover > all the corner cases. That's fine, I understand. That's why I'm asking, I'm sure you will know better if such a feature would be any useful. (In reply to comment #5) > What I meant is that stack traces are more complex than regular search phrases > entered in the "Find Text". Especially when combined with "fuzzy searches" as > mentioned in bug 198497. Please note that fuzzy search isn't meant to be based on the stack traces, but rather go on the plain text. > The compare editor I would like to provide wouldn't have to know about the fact > that there is more than one stack trace. I would expect a stream that contains > the stack trace. Mylyn specific support would need to extract the stream for the > proper stack trace. Mylyn can indeed extract the stack trace from the editor, but currently it can do that only for editor you are searching duplicates from (basically it will take the first stack trace). However the search hits are matched by the issue tracker search engine and can pickup not only the first stack trace but any stack trace that is posted in comments. In result, the correct duplicate will be found, but we don't really know which of the stack trace gave the hit. Even if you'll add some code to automatically find the right stack trace, we are practically back to the "trust" issue. You will have to either trust Mylyn that it did found the right stack trace, or will have to manually select which stack trace to compare on. For the latter, UI will be quite complex and there is also issue that this stack trace comparison feature should be somehow only activated for specific duplicate detectors and not for all of them (i.e. "fuzzy search" one won't have any stack traces to compare). Tomasz: I agree with your use case and explanations. The problem is that no matter what heuristic a stack trace based duplicate detector uses, it will always report imperfect matches which result in false positives. In fact, one of the key problems we have with it right now is that it is too strict (bug 161877). Since there are bound to be false positives, users are bound to find themselves in the same situation as you, in wanting to compare the source stack trace with the matched stack traces. The fact that the user doesn't know which stack traces were used for the matching is just part of the problem. The UI for this would be tricky. If you're interested in contributing this, why don't you propose a UI for how it could work and we can iterate? I agree that a compare style dialog makes sense for the actual matching, and perhaps you can come up with something where the source of the compare is the source task, and the matches show up with comments in the target side and the user could click through comments that contain stack traces. Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn |