Bug 846389 - kerneloops bugzilla report loses comment
kerneloops bugzilla report loses comment
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libreport (Show other bugs)
16
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: abrt
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-07 12:11 EDT by Oliver Henshaw
Modified: 2012-08-29 20:58 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-29 20:58:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Oliver Henshaw 2012-08-07 12:11:25 EDT
Description of problem:

I recently reported two kernel oops warnings with abrt. For each one I entered a comment giving some context but the comment didn't appear in the filed bug.

The two examples are bug 846045 comment 1 and bug 845343. In each case I can still see the comment I wrote in .abrt/spool/oops-TIMESTAMP/comment


Version-Release number of selected component (if applicable):

abrt-addon-kerneloops-2.0.7-3.fc16.x86_64
libreport-plugin-kerneloops-2.0.10-3.fc16.x86_64
Comment 1 Jakub Filak 2012-08-08 04:03:48 EDT
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.
Comment 2 Oliver Henshaw 2012-08-08 07:21:25 EDT
(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.
Comment 3 Jakub Filak 2012-08-08 09:20:53 EDT
(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.
Comment 4 Dave Jones 2012-08-08 11:06:33 EDT
> 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.
Comment 5 Oliver Henshaw 2012-08-08 11:55:44 EDT
(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.
Comment 6 Jakub Filak 2012-08-08 15:56:04 EDT
(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.
Comment 7 Jakub Filak 2012-08-14 03:17:18 EDT
commit 51efa4446d8cf30c88d0b31a9b26a9223fecdaee
Author: Jakub Filak <jfilak@redhat.com>
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@redhat.com>
Comment 8 Fedora Update System 2012-08-14 10:33:22 EDT
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
Comment 9 Fedora Update System 2012-08-23 19:29:54 EDT
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).
Comment 10 Fedora Update System 2012-08-29 20:58:46 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.