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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
