On Mon, 2010-01-18 at 17:02 -0500, Paul W. Frields wrote: > On Mon, Jan 18, 2010 at 01:59:27PM -0700, Stephen John Smoogen wrote: > > I just wanted to say thanks to the guys who integrated ABRT into F12. > > It has rough edges and I know it needs improvement, but I have filed > > more 'bugs' than in many past releases where instead I just let things > > slide. Most of the items I have run into have been fixed and I have > > tried to help the engineers who have asked for info. > > > > Thankyou. > > I don't think anyone, including the guys working on ABRT, would claim > it's perfect. *Except* in that it's 100% better than what we had > before. ;-) > > I'm in the same boat as Smooge; ABRT is a huge time saver for me for > filing bugs, which means I can contribute more, even when filing bugs > is really outside my daily work. That tells me it's a significant > step down the right path. I know the developers are grateful for > constructive input and want to improve ABRT. Thanks to *everyone* for > being a part of that process. It's a definite + on a user side; but making it a + on the developer side is going to be difficult. Developers will get many more bugs reported, yes, but: * Even when developer gets a lot of a *perfectly good* bug reports, it's hardly makes him feel happy. It's more work. On a subconscious level, many of them won't feel particularly impressed by it, even though good bug reports is objectively a good thing. * Some users will not bother visiting bz entries they created with abrt help and will not provide adequate descriptions, not to mention will not respond to any further questions. Developers won't like it, and some developers will blame abrt. This cannot be fixed by abrt - PEBKAC. abrt can only try to collect _some_ information about the crash, but it never will be as good as a cooperative user can provide. This is a classic downside of making in easier to report problems: now you have many "lower quality" reporters. * Inevitably there will be crashes caused by the single bug which look sufficiently different for abrt to not recognize them as dupes, and from time to time there will be "bz floods" when single bug results in hundreds on bz's created. Developers DEFINITELY won't like it, and most developers will blame abrt. abrt _must_ try hard to prevent it, but it can't be prevented with 100% probability. * Crashes caused by library bugs will be misattributed to wrong package. In this case, _developers of the package_ will feel the pain, not _library developers_, and if library developers aren't responsive (or just slow to respond), package developers will endure a deluge of abrt reports while bug is not fixed, which can be months. What they will think? "F*cking bugs, f*cking lib, f*cking ABRT". Can I blame them? Hardly. * Not to mention that a single bug in abrt can easily create a bad bz flood for many packages at once. And today, abrt is not yet a mature package, so bugs are somewhat likely. :( So it's not going to be an easy sailing for ABRT and developers. Be prepared. On ABRT side, we will try to make it not so horrible. Honest. -- vda -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
