Bug 670342

Can you please give me a bug number? Btw, pressing ctrl-c in python programs (like yumex) throws a KeyboardInterrupt exception and if program doesn't handle it it dies with an error message, but technically it's not an error.

Bug 655160 was the one that matched abrt's report.

Yes, ctrl-c is not technically an error, but the yumex process had hung for over 6 hours; hitting ctrl-c or killing the process was the only way out.  I had hoped that the stack trace would have helped diagnose the hang, but I guess not.

I've submitted the real yumex report as bug 670341.

I suppose yumex is not important in this instance.  If some random program dies, and abrt won't upload the stack trace because someone was previously unable to reproduce the bug and set it to 'closed, worksforme', then the bug will never be fixed, even if a hundred other people subsequently do encounter it and try to submit it.  According to the database, it was an erroneous bug report, whereas it was actually an erroneous QA result and a very serious bug; a bugzilla reviewer would never be able to tell.

(In reply to comment #2)
> I suppose yumex is not important in this instance.  If some random program
> dies, and abrt won't upload the stack trace because someone was previously
> unable to reproduce the bug and set it to 'closed, worksforme', then the bug
> will never be fixed, even if a hundred other people subsequently do encounter
> it and try to submit it.

True. However, there is another scenario, when developer wants the bug to stay "closed, worksforme", and abrt keeps reopening it.

What developer can do to stop it? Nothing!

Granted, this scenario looks not very likely - it means that developer isn't doing his job well (he has either close the bug with correct diagnosis - NOTABUG, WONTFIX, whatever; or he should keep it open which it is not fixed).

However, I think in general programs should not try to outsmart people. If developer said "CLOSED", then it's closed, end of story. If developer is wrong, well, tough luck.

Another angle here is that ABRT should lean towards not opening a bug when there's a possibility it's not a real bug after all.

> According to the database, it was an erroneous bug report, whereas it was actually an erroneous QA result and a very serious bug; a bugzilla reviewer would never be able to tell.

Bottom line: developers should be careful to not close/worksforme bugs when they are not sure. A program (ABRT) can't help with that.


That said, I'm not feeling particularly strong about it. If you strongly disagree, let me know.

...and if the reporter feels the bug should be re-opened he can do it manually or create a new bug with proper explanation why it shouldn't  be treated as NOTABUG or WONTFIX, this is imho much better then abrt re-opening hundreds of bugs reasonably closed by developer as NOTABUG/WONTFIX.

I'm inclined to agree with both of you; if abrt tries to report a bug that has been analyzed and found to be NOTABUG or WONTFIX, that should be the end of it.  

In this particular case, the 'bug' was the user hitting ctrl-c due to a hang, but abrt incorrectly matched it with a different bug in yumex that was "closed, worksforme".  Does this mean that from now on, some or all bugs found in yumex (by abrt) will be matched with the closed bug and be rejected?  Over time, if this incorrect matching could occur for any program, more and more programs would be excluded from submitting any bugs via abrt+bugzilla, which greatly limits its utility.

The other problem is that ctrl-c in yumex *did* trigger abrt to do something.  Rather than try and fix abrt in order to ignore false alarms, perhaps yumex (and other python programs) should be fixed to quit more gracefully and not create those false alarms.  That's what they do to school kids who pull fire alarms.  :-)

And don't forget the user's perceptions.  The initial user reaction in my case was "This program was solidly hung for 6 hours, how dare they dismiss this report with a 'worksforme' before any human actually read the report?".  It felt like a slap in the face.  I figured you'd like to know about that, because not every user is as understanding and forgiving as yours truly.

Thanks!

(In reply to comment #5)
> I'm inclined to agree with both of you; if abrt tries to report a bug that has
> been analyzed and found to be NOTABUG or WONTFIX, that should be the end of it. 
> 
> In this particular case, the 'bug' was the user hitting ctrl-c due to a hang,
> but abrt incorrectly matched it with a different bug in yumex that was "closed,
> worksforme".  Does this mean that from now on, some or all bugs found in yumex
> (by abrt) will be matched with the closed bug and be rejected? 

No, not all bugs. Bugs are wrongly declared duplicates only if we have bugs in our duplicate detection.


> Over time, if
> this incorrect matching could occur for any program, more and more programs
> would be excluded from submitting any bugs via abrt+bugzilla, which greatly
> limits its utility.

Hmm. I guess we'd need to periodically purge abrt tags from really old bugs...


> And don't forget the user's perceptions.  The initial user reaction in my case
> was "This program was solidly hung for 6 hours, how dare they dismiss this
> report with a 'worksforme' before any human actually read the report?". 

The problem here is that automatic bug reporting can only do so much.

When things get complicated, reporter needs to engage his brain. In this case, after looking at the data, he probably needed to reopen the bug, or create another one by hand.

Closing as WONTFIX