Bug 846389
Summary: | kerneloops bugzilla report loses comment | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Oliver Henshaw <oliver.henshaw> |
Component: | libreport | Assignee: | abrt <abrt-devel-list> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 16 | CC: | abrt-devel-list, dvlasenk, iprikryl, jfilak, jmoskovc, kklic, mlichvar, mmilata, mnowak, mtoman |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-08-30 00:58:46 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Oliver Henshaw
2012-08-07 16:11:25 UTC
In case of kerneloops ABRT doesn't use a comment in bz comment 0 because kernel guys are not interensted in user's comments (bug 795548). It is a pitty to ask user for entering a description and then silently omit the user's input in bz. At least, ABRT should post user's input in bz comment 1. (In reply to comment #1) > In case of kerneloops ABRT doesn't use a comment in bz comment 0 because > kernel guys are not interensted in user's comments (bug 795548). By my reading, that bug concerned smolt info (and the reporter would have been happy with a link to a smolt profile); comments were not mentioned at all. Perhaps you meant bug 711591? Again, by my reading, the reporter regarded the literal 'Comment ------' string as unnecessary, they didn't say that the comment itself was always unnecessary. Per bug 711591 comment 1, allowing the comment field to be disabled for certain packages seem the wrong approach - configuring whether the comment field is mandatory for that package would be better. It's also instructive to look at the example bugs cited in bug 795548 and bug 711591: * Bug 702723 has no comment field from the reporter but further comments from duplicate reporters do have a comment field. * Bug 795544 comment 4 implies that the reporter had written a comment explaining the context for this oops, but this was nowhere to be found in bug 795544 comment 0; bug 795544 comment 1 suggests kernel developers do sometimes want this information. Both these bug reports pre-date commit f01bb3bc293f91eacb9196229746ab95580f8b58 so the absence of comment fields in comment 0 may be a pre-existing issue. (In reply to comment #2) > (In reply to comment #1) > Perhaps you meant bug 711591? Again, by my reading, the reporter regarded > the literal 'Comment ------' string as unnecessary, they didn't say that the > comment itself was always unnecessary. > > Per bug 711591 comment 1, allowing the comment field to be disabled for > certain packages seem the wrong approach - configuring whether the comment > field is mandatory for that package would be better. > You are right. bug 711591 is the original request for "removal" of the unnecessary comments (sorry for that, I searched only in git log). Anyway, bug 711591 was satisfied only partially. The missing part of this bug has been implemented in bug 795548. A decision to not include a comment has been made (cite bug 795548 comment 0 : "The stack trace is all we need there.", it can explain the Commit f01bb3bc293f91eacb9196229746ab95580f8b58) but the comment field has not been disabled. Therefore, you can fill the comment field but your comment is omitted in bz. > > It's also instructive to look at the example bugs cited in bug 795548 and > bug 711591: > * Bug 702723 has no comment field from the reporter but further comments > from duplicate reporters do have a comment field. > * Bug 795544 comment 4 implies that the reporter had written a comment > explaining the context for this oops, but this was nowhere to be found in > bug 795544 comment 0; bug 795544 comment 1 suggests kernel developers do > sometimes want this information. > Both these bug reports pre-date commit > f01bb3bc293f91eacb9196229746ab95580f8b58 so the absence of comment fields in > comment 0 may be a pre-existing issue. Reporters are allowed to report a bug without a comment through report-cli. Therefore, I guess, both of bug 702723 and bug 795544 have been reported by report-cli and reporters haven't wrote any comment. I still think that posting users comments in bz comment 1 is better than omitting them. > I still think that posting users comments in bz comment 1 is better than omitting them.
FWIW, I agree. I'm not sure how my previous bug reports have been interpreted as 'throw away the users hand-typed report', but that wasn't the intent.
The 'unnecessary comments' remark was a request to indicate to the user "this comment is going to be filed as a comment" so they wouldn't type garbage into the box.
(In reply to comment #4) > The 'unnecessary comments' remark was a request to indicate to the user > "this comment is going to be filed as a comment" so they wouldn't type > garbage into the box. I wonder if the reason for garbage comments is that the comment field is/was mandatory, or at least strongly encouraged, (when it's not off) - which is why I suggested above that the abrt reporter gui should only nag users when filing bugs for packages whose maintainers want the comment field to be mandatory. In this case disabling the comment field for other packages is solving the wrong problem. (In reply to comment #5) > (In reply to comment #4) > > The 'unnecessary comments' remark was a request to indicate to the user > > "this comment is going to be filed as a comment" so they wouldn't type > > garbage into the box. > > I wonder if the reason for garbage comments is that the comment field is/was > mandatory, or at least strongly encouraged, (when it's not off) - which is > why I suggested above that the abrt reporter gui should only nag users when > filing bugs for packages whose maintainers want the comment field to be > mandatory. In this case disabling the comment field for other packages is > solving the wrong problem. The comment field is not mandatory in the latest version. kernel is the only component having special casing. commit 51efa4446d8cf30c88d0b31a9b26a9223fecdaee Author: Jakub Filak <jfilak> Date: Thu Aug 9 18:37:40 2012 +0200 rhbz#846389: generate koops description according to rhbz std template New kernel bug reports is to be created according the following template: <if comment exists:> Description of problem: <$user's comment> <fi> Additional info: libreport version: <$libreport version> abrt_version: <$abrt version> cmdline: <$cmdline> kernel: <$kernel version> tainted_long: <$tainted long if present> backtrace: <$stack trace> No files attacheced. Signed-off-by: Jakub Filak <jfilak> btparser-0.18-2.fc17, abrt-2.0.11-2.fc17, libreport-2.0.12-4.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/FEDORA-2012-11529/abrt-2.0.11-2.fc17,libreport-2.0.12-4.fc17,btparser-0.18-2.fc17 Package abrt-2.0.12-1.fc17, libreport-2.0.13-1.fc17, btparser-0.18-2.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing abrt-2.0.12-1.fc17 libreport-2.0.13-1.fc17 btparser-0.18-2.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-11529/abrt-2.0.12-1.fc17,libreport-2.0.13-1.fc17,btparser-0.18-2.fc17 then log in and leave karma (feedback). abrt-2.0.12-1.fc17, libreport-2.0.13-2.fc17, btparser-0.18-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. |