Backtracing, Invalidated Bugs and Quality

[Alexander Sack]

On Wed, Aug 20, 2008 at 07:39:40AM -0400, Scott Kitterman wrote:
> On Wed, 20 Aug 2008 19:42:31 +1000 "Null Ack" <nullack at gmail.com> wrote:
> >Evening Devs,
> >
> >Tonight I was doing some of my test suite and I had the
> >tracker-preferences crash unexpectedly doing routine workflow with
> >viewing (not changing) preferences. Apport came through and I ended up
> >at an invalid existing bug from 2007 because the user had not
> >submitted debugging symbols. This has happened to me before and my
> >mind has been busy since with thinking about how this detracts from
> >quality and what to do about it. These are real bugs, some of them are
> >in production, that are not being fixed.
> 
> I think this is important.  It seems to me that marking bugs invalid 
> because they don't have enough information to fix them detracts from having 
> a good understanding of the state of our system.  

I am not sure about what kind of crash bugs you are talking. Do those
have a proper symbolized backtrace? If so, they should definitly stay
open ... unless we have indications that the bug might be fixed
(e.g. no duplicates for ages on a frequently used package paired with
a missing testcase).

But there are also many crash reports where the retracers fail and we
dont have any testcase. You want those to stay open as well?

> 
> Crashes are particularly problematic since duplicates of invalid bugs do 
> not show in the default search results.  This means that if apport rightly 
> dupes to a bug marked invalid, it can automatically become essentially 
> invisible.

Thats a bug in the apport service. IMO an invalid crash report should
be reopened (somehow) if it receives a new duplicate. However, given
the judgement above, I dont see why good backtraces would go to
invalid state at all.

 - Alexander