| Summary: | Upload Backtraces only as Attachment to Bug Report instead of posting it in the Comment | ||
|---|---|---|---|
| Product: | [Applications] drkonqi | Reporter: | Richard Llom <richard.llom> |
| Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | CC: | adaptee, mail |
| Priority: | NOR | ||
| Version: | 2.1.5 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=248807 https://bugs.kde.org/show_bug.cgi?id=415100 |
||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | kate Backtrace added by DrKonqi | ||
|
Description
Richard Llom
2013-03-21 16:28:35 UTC
Created attachment 78271 [details] kate Backtrace added by DrKonqi Application: kate (3.10.1) KDE Platform Version: 4.10.1 Qt Version: 4.8.4 Operating System: Linux 3.7.6-2-CHAKRA x86_64 Distribution: "Chakra Linux" -- Information about the crash: - What I was doing when the application crashed: [[This is an example of how I would suggest a DrKonqi comment.]] Possible duplicates by query: bug 316513, bug 315664, bug 311944, bug 308595. Reported using DrKonqi Well, if you consider how developers/triagers read mails sent for new crash report in their favorite mail clients , you will realize it is bad idea to only add short summary in the mail and put full information as attachment : the summary is often not enough to show what the real problem is, so I will need to open the attachment for full information in order to see which component is actually problematic and then reassign if necessary. Really inefficient. Another thing is attachment is unsearchable through bugzilla, really bad for identifying duplicates and filtering. As developer and traiger myself, I find the current combination of "full information for new reports " and "summary and attachment for amended reports" good enough. If I want to make any change, it would only be making the summary containing even more information instead of the opposite. Anyway, for a crash report containing dozens of duplicates/comments, only the original report(comment #0) contains the full information, so I really don't think that would introduce great clutter. Also bugzilla web interface makes it easy to fold/unfold comments. > Well, if you consider how developers/triagers read mails sent for new crash > report in their favorite mail clients , ... I didn't thought of that, that is a valid point. > Another thing is attachment is unsearchable through bugzilla, really bad for > identifying duplicates and filtering. Ok, that would be an upstream problem. But in case of bug 258505 and bug 287038, the backtrace in comment section doesn't seem to work so flawlessly either. > As developer and traiger myself, I find the current combination of "full > information for new reports " and "summary and attachment for amended > reports" good enough. If I want to make any change, it would only be making > the summary containing even more information instead of the opposite. > I actually would like to see such a duplicate comment. Because currently this feature seems to be broken in kqnqi (see bug 316958). > Anyway, for a crash report containing dozens of duplicates/comments, only > the original report(comment #0) contains the full information, so I really > don't think that would introduce great clutter. Also bugzilla web interface > makes it easy to fold/unfold comments. (In reply to comment #3) > > Another thing is attachment is unsearchable through bugzilla, really bad for > > identifying duplicates and filtering. > Ok, that would be an upstream problem. But in case of bug 258505 and bug > 287038, the backtrace in comment section doesn't seem to work so flawlessly > either. The searching for duplicates is not perfect, but moving full information from comment into attachment only makes the situation worse. > > > As developer and traiger myself, I find the current combination of "full > > information for new reports " and "summary and attachment for amended > > reports" good enough. If I want to make any change, it would only be making > > the summary containing even more information instead of the opposite. > > > I actually would like to see such a duplicate comment. Because currently > this feature seems to be broken in kqnqi (see bug 316958). I have read that one and added my comment before. Since you have raised it again, I will do some real experiment to see whether it is really broken. For now https://bugs.kde.org/show_bug.cgi?id=315704#c1 looks like a good working example: it is amended from 4.10.0, and the change of drkonqi between 4.10.0 and 4.10.1 is basically zero when it comes to code. |