bugzilla bugzappers?

[Jiri Moskovcak]

Hi,
some possitive news from me first:
We have a new backtrace parser which should be able to find the 
duplicates much better (tested on every known dupes reported by ABRT so 
far) so at least the number of dupes should lower once this out (we're 
having some troubles with SELinux so it didn't make it to the repos 
before F14 :( )

...and for the rest I'll try to answer as much as I can, so here we go:

Q: How many of these fixed bugs would not have been fixed if abrt wasn't 
around. My (wild) guess is, not much more, because serious and
reproduceable bugs would have been manually reported in any case.

A: Hm, maybe even more interesting figures would be how long would it
take until it's reported for the first time, so how soon the devel would 
be notified about the crash...

Q: How many of the "unfixed bugs" remained unfixed because abrt's 
reports are not reporting sufficient information to allow maintainers to 
investigate.

A: I don't understand this, if the bug is reproducible then a lot of 
users will sooner or later hit it, so someone will provide more info.. 
If it's just one occurence and the reporter is not responsive, then the 
bug probably doesn't bother him or anyone else anymore, so it's safe to 
let the bugzapper to close it (or do it manually as INSUFF_DATA)

Q: As far as the packages I am maintaining are concerned, I
haven't been able to fix any bug in my packages due to abrt reports.

A: That's unfortunate, as ABRT's main idea is to provide such 
information, please send me an email which data you're missing and we 
will add it to the ABRT report (if it can be gathered automatically) or 
I can just add it to blacklist if ABRT is not able to provide such 
informations.

Q: As far as I as a user am concerned, none of the bugs I had reported 
via abrt was fixed.

A: If you filled a good report (which I have no doubt you did!) then 
it's the packager to blame not ABRT.

Q: Of the 28 abrt bugs filed against my packages, I think 1 resulted in 
a real fix that I needed to apply as a packager.  Another was fixed by 
an update. The rest are piling up.  I don't have the time to fix them
myself. I rarely get any response to my requests for more info (5 are
in needinfo). I haven't been able to get upstream to involved.  I'm
seriously considering orphaning pdfedit (14 bugs) over this.

A: It's not possible for ABRT to determine if the bug was caused by 
Fedora specific patch or by an upstream code, so just forwarding it to 
upstream is really not good idea. If those bugs are serious - affecting 
a lot of people then upstream should care, if they don't it's 
unfortunate, but nothing what ABRT should be blame for...

Q: Its been somewhat a disappointing experience. Not because of the % of
the bugs fixed, but because of the % response. I'm not sure if any of my
bugs have been responded to. There are probably one or two. I've been
annoyed that some of the bugs are getting many many CC's added to them
(or the ones I've been added to), but no response.

A: If you filled the "how to reproduce" and provided a good description
and there was a lot of people CCed on the bug, then not-responding to
the report just shows the nature of the packager... (please don't start
a flame about this, I know there might be bugs with a lot of CC and no
usable comment, but c'mon how many of such bugs is there?)

Q: The extreme inefficiency comes from the bugs that I can't reproduce,
the upstream can't reproduce, and the user isn't responding. And this
happens *a lot*. Most of the time, they don't even put down the steps
to reproduce.

A: Agree, the way I handle these bugs is to ask user for steps to 
reproduce or at least some hints, if he doesn't respond in some time, I 
just close it as INSUFFICIENT_DATA, there is really nothing more you can do.

Q: Can we at least mandate including the steps to reproduce
in the ABRT reports?

A: We can, but I'm really not sure how to write a logic that will check 
the if the steps make sense or if it's just "lorem ipsum" ...

Q: > > On one hand it's a systematic way to report bugs, on the other 
hand it
 > > forces me download debug packages and to struggle with its GUI.
 > > Considering the facts that downloading 100MBs of debug-packages may 
not
 > > always be applicable (E.g. when not having broadband access), that 
abrt
 > > not always manages to correctly handle debug-infos, this costs.
 > >
 > > That said, I repeatedly ended up with "deleting" abrt notifications 
and
 > > to ignore it.
This is another thing where we don't have any trouble identifying the
problem and the solution. Will Woods has had the debuginfofs system
sketched out for years to deal with this. What he doesn't have is the
time to write it (since he's busy with AutoQA). Anyone else could do it
instead, though.

A: There is a few projects trying to deal with this, some of them should 
be ready for F15 we will be more than happy for some feedback on this, 
so together we make sure it's going the right direction...

http://fedoraproject.org/wiki/Features/RetraceServer
http://fedoraproject.org/wiki/Features/DebuginfoFS


Q: It's the "nagging"/"non-crasher" class of bugs, which is really 
reducing the "user-experience" of Fedora, exactly the class of bugs 
"abrt" is not designed to to not cover.

A: Such bugs can be easily reported using the BZ's web page as it's more 
an essay then a bug report, so no additional data or user skills 
required for such bugreport...

Q: Wasn't there some way for a maintainer to opt out of abrt?
I remember seeing this being discussed but cannot find how to do it on
the abrt trac or in the man-pages.

A: The maintainer who can't handle the number of ABRT reports or thinks
that ABRT can't provide any usefull information about crash in his 
package (or has some other good reason) can always ping me and I will 
add this package to ABRT's blacklist in it's default configuration. I'm 
not sure if we should allow packager to blacklist their packages without 
asking us first, but if there will be a lot of you asking for it, I'm 
not against it...


Hope this clears some things out,
Jirka