assigning of abrt crashes

[Colin Walters]

Hi,

I'd like to propose a general rule that ABRT crash logs should remain
"assigned" to the actual application, unless an actual investigation
has been done and there's a "reasonable" certainty the flaw is in the
library code in which it happened to crash.

Rationale: Applications are more likely to be buggy (I'm just
asserting this, but it seems obvious), and just because a crash
happened inside the library, particularly when C/C++ is involved,
means nothing; the flaw could still be in the application.  If we
reassign them, it's harder to make all crashes for an application
visible.

I'm fine with being added to a CC list, but reassigning is more of a mess.

Sample crash: https://bugzilla.redhat.com/show_bug.cgi?id=624098

[Thomas Spura]

On Mon, 16 Aug 2010 11:01:36 -0400
Colin Walters wrote:

>  Hi,
>  
>  I'd like to propose a general rule that ABRT crash logs should remain
>  "assigned" to the actual application, unless an actual investigation
>  has been done and there's a "reasonable" certainty the flaw is in the
>  library code in which it happened to crash. 
Who should do that investigation, when the maintainer of the actual
application is unable to do so? A bug tracker with
FE-NEEDSHELPWITHBACKTRACE would help here. Maybe FES [1] would like to
help here in that case.

>  Rationale: Applications are more likely to be buggy (I'm just
>  asserting this, but it seems obvious), and just because a crash
>  happened inside the library, particularly when C/C++ is involved,
>  means nothing; the flaw could still be in the application.  If we
>  reassign them, it's harder to make all crashes for an application
>  visible.
>  
>  I'm fine with being added to a CC list, but reassigning is more of a
>  mess. 
Simply CC'ing would always work, because how can I be sure, that
someone with more experience with backtraces will try to track this
down, if I can't?


	Thomas

[1] http://fedoraproject.org/wiki/Fedora_Engineering_Services

[Colin Walters]

On Tue, Aug 17, 2010 at 6:06 AM, Thomas Spura <tomspur(a)fedoraproject.org&gt; wrote:
>  On Mon, 16 Aug 2010 11:01:36 -0400
>  Colin Walters wrote:
>
> > Hi,
> >
> > I'd like to propose a general rule that ABRT crash logs should remain
> > "assigned" to the actual application, unless an actual investigation
> > has been done and there's a "reasonable" certainty the flaw is in the
> > library code in which it happened to crash.
>
>  Who should do that investigation, when the maintainer of the actual
>  application is unable to do so? A bug tracker with
>  FE-NEEDSHELPWITHBACKTRACE would help here. Maybe FES [1] would like to
>  help here in that case. 
Try the upstream author first?

[Thomas Spura]

On Tue, 17 Aug 2010 10:49:29 -0400
Colin Walters wrote:

>  On Tue, Aug 17, 2010 at 6:06 AM, Thomas Spura
>  <tomspur(a)fedoraproject.org&gt; wrote:
>  > On Mon, 16 Aug 2010 11:01:36 -0400
>  > Colin Walters wrote:
>  >
>  >> Hi,
>  >>
>  >> I'd like to propose a general rule that ABRT crash logs should
>  >> remain "assigned" to the actual application, unless an actual
>  >> investigation has been done and there's a "reasonable" certainty
>  >> the flaw is in the library code in which it happened to crash.
>  >
>  > Who should do that investigation, when the maintainer of the actual
>  > application is unable to do so? A bug tracker with
>  > FE-NEEDSHELPWITHBACKTRACE would help here. Maybe FES [1] would like
>  > to help here in that case.
>  
>  Try the upstream author first? 
Without a clear way "how to reproduce" it, they can't help here (that
was the answer in some other bugs of pychess). The python-visual
authors even said, that they never saw a backtrace and can't help at
all.

So some upstream author would help, but what in the cases, they
don't/can't?
Ignoring the bugs till the release is EOL is not really an option...

[Colin Walters]

On Tue, Aug 17, 2010 at 11:12 AM, Thomas Spura
<tomspur(a)fedoraproject.org&gt; wrote:
>  Without a clear way "how to reproduce" it, they can't help here 
One advantage of automated collection (or semi-automated like ABRT) is
that given enough crashes, it can be easier to track down the root
cause.  So it's useful to have the report logged, even if we can't
take immediate action on it.

>  So some upstream author would help, but what in the cases, they
>  don't/can't? 
Then keep it around until it becomes useful.

>  Ignoring the bugs till the release is EOL is not really an option...
So for the reasons above there's no problem with leaving the report in
the system.  Remember also that a certain percentage of crashes are
going to happen simply due to bad hardware.  We have to accept noise
in the system.  Crashes aren't bugs; they're crashes that may be bugs.

[Thomas Spura]

On Tue, 17 Aug 2010 11:20:18 -0400
Colin Walters wrote:

>  On Tue, Aug 17, 2010 at 11:12 AM, Thomas Spura
>  <tomspur(a)fedoraproject.org&gt; wrote:
>  >
>  > Without a clear way "how to reproduce" it, they can't help here
>  
>  One advantage of automated collection (or semi-automated like ABRT) is
>  that given enough crashes, it can be easier to track down the root
>  cause.  So it's useful to have the report logged, even if we can't
>  take immediate action on it.
>  
>  > So some upstream author would help, but what in the cases, they
>  > don't/can't?
>  
>  Then keep it around until it becomes useful.
>  
>  > Ignoring the bugs till the release is EOL is not really an option...
>  
>  So for the reasons above there's no problem with leaving the report in
>  the system.  Remember also that a certain percentage of crashes are
>  going to happen simply due to bad hardware.  We have to accept noise
>  in the system.  Crashes aren't bugs; they're crashes that may be bugs. 
Ok, makes sense. I'll CC'ing you the next time, when such a crash
happens (and I suspect pygobject to do something wrong) and not
completely reassign it.

[drago01]

On Mon, Aug 16, 2010 at 5:01 PM, Colin Walters <walters(a)verbum.org&gt; wrote:
>  Hi,
>
>  I'd like to propose a general rule that ABRT crash logs should remain
>  "assigned" to the actual application, unless an actual investigation
>  has been done and there's a "reasonable" certainty the flaw is in the
>  library code in which it happened to crash.
>
>  Rationale: Applications are more likely to be buggy (I'm just
>  asserting this, but it seems obvious), and just because a crash
>  happened inside the library, particularly when C/C++ is involved,
>  means nothing; the flaw could still be in the application.  If we
>  reassign them, it's harder to make all crashes for an application
>  visible.
>
>  I'm fine with being added to a CC list, but reassigning is more of a mess.
>
>  Sample crash: https://bugzilla.redhat.com/show_bug.cgi?id=624098 
Hah I proposed the opposite here:
https://bugzilla.redhat.com/show_bug.cgi?id=603289 ... in my case I
get lots of compiz bugs that a clearly mesa / driver bugs and all I
can do do is to reassign them.
I got tired of doing that so I filed said bug.

[Przemek Klosowski]

On 08/17/2010 01:11 PM, drago01 wrote:
>  On Mon, Aug 16, 2010 at 5:01 PM, Colin
> Walters<walters(a)verbum.org>  wrote:
> > Hi,
> >
> > I'd like to propose a general rule that ABRT crash logs should remain
> > "assigned" to the actual application, unless an actual investigation
> > has been done and there's a "reasonable" certainty the flaw is in the
> > library code in which it happened to crash.
> >
> > Rationale: Applications are more likely to be buggy (I'm just
> > asserting this, but it seems obvious), and just because a crash
> > happened inside the library, particularly when C/C++ is involved,
> > means nothing; the flaw could still be in the application.  If we
> > reassign them, it's harder to make all crashes for an application
> > visible.
> >
> > I'm fine with being added to a CC list, but reassigning is more of a mess.
> >
> > Sample crash: https://bugzilla.redhat.com/show_bug.cgi?id=624098
>
>  Hah I proposed the opposite here:
>  https://bugzilla.redhat.com/show_bug.cgi?id=603289 ... in my case I
>  get lots of compiz bugs that a clearly mesa / driver bugs and all I
>  can do do is to reassign them.
>  I got tired of doing that so I filed said bug. 
Since there's no systematic way of figuring out if it's the app or the 
library, perhaps the bug should be filed against both? I don't think 
Bugzilla allows specifying two components for the same bug so it would 
have to be two separate bugs, which sounds heavy-handed. Two mitigating 
circumstances are:

- abrt would only do it if the stack trace clearly indicates that a 
library is involved

- bug reviewers can quickly close the superfluous one