On Wed, 2010-11-03 at 22:12 -0400, Orcan Ogetbil wrote:
On Wed, Nov 3, 2010 at 9:55 PM, Adam Williamson wrote:
On Wed, 2010-11-03 at 21:02 -0400, Orcan Ogetbil wrote:
Maybe it is time to discuss the usefulness of ABRT to Fedora. I think that it is a great idea for commercial products such as RHEL, but it obviously did not fit Fedora as is.
I disagree. I have seen many bugs fixed with the aid of abrt feedback. It beats the hell out of a bug report which says 'it crashed'.
Does it compare to this number? (it takes a while to open)
Not hard to run the numbers. There've been 31,603 bugs reported to Bugzilla by abrt. There are 2,216 bugs reported by abrt that have been closed as CURRENTRELEASE, RAWHIDE, ERRATA or NEXTRELEASE (which are the resolutions that usually imply 'it got fixed'). I think a tool that's resulted in 2,216 fixes for crasher bugs is pretty cool. :)
(I just searched for bugs with [abrt] in the subject reported against Fedora, which gives the 31,603 total, then ran the same search but with the above resolution restrictions).
From what I have seen, the maintainers are more responsive to manually filed bugs than to ABRT filed bugs (Am I wrong?). Apparently the current setup is driving users (such as the person in the above email) away who are otherwise willing to report bugs. This is not good.
What can we do to make it better? Some ideas:
- ABRT stops reporting new bugs to Fedora.
- The user does a self evaluation: Is the bugcoding related, or
packaging related?
- If he thinks the bug is packaging related, or if he's not sure, he
manually files a bug to Fedora bugzilla. Otherwise he notifies the developers.
- The package maintainer asks for a backtrace
- User reproduces the crash, and puts the bug number in ABRT gui. ABRT
posts the backtrace to the bug report as an attachment.
- If the bug is coding related, the package maintainer can direct the
user to the developers.
Hence I added "if he's not sure". Please read again.
My point is that you may as well not bother with the cases where the user is sure, because they'll be very rare, and such users will know what to do anyway.
This is not practical. Users are not in a position to know whether the crash is in downstream or upstream code.
There can be a checkbox in pkgdb for maintainers to turn off ABRT bug reporting for their packages.
This seems reasonable, for packagers who are not in a position to act on such reports, but then, that's not a great position for a packager to be in; for instance, I'm a packager who can't code so these reports are of fairly limited value to me directly, but they would at least give me good data to pass to the upstream coders of any package I own.
I played the middle man in some of the bug reports. The user did not seem to want to contact the developer directly. The upstream asked for something, and I forwarded it to the user. This went back and forth a couple times until I realized that this was highly inefficient, and mostly a waste of time (since one of the parties gave up eventually). There's got to be a better way.
I'm not sure there is. Implementing a whole separate system for abrt to report to is essentially just institutionalizing the middle-man. But hey, if we go that way, fine. It's worth noting, though, that we're not short of proposals for implementing an intermediary system for abrt, we've already had one for a while. We're short on people *writing* the intermediary system.