Backtracing, Invalidated Bugs and Quality

HggdH hggdh2 at gmail.com
Thu Aug 21 06:13:12 UTC 2008


On Wed, 2008-08-20 at 12:46 -0400, Scott Kitterman wrote:

> > "Incomplete" is a warning that the report isn't useful 
> > in its current state, and will soon be treated accordingly 
> > unless it's made more useful.
> >
> That is certainly that is 'a' purpose, but not the only one.
> Understanding the state of a package or distro is another purpose.
> 
> By marking incomplete backtrace crash bugs invalid we lose 
> information both about circumstances of crashes and frequency.  
> A bug with 50 dupes and one good backtrace is different than 
> one with no dupes.  Reading the dictionary definition of 
> 'invalid', I don't think it's correct. 

Indeed. Meaning in a context has to be explicitly defined somewhere.
For the bug stati, it is here: https://wiki.ubuntu.com/Bugs/Status .
There the meaning of "Invalid" is well defined, even if it does not
(fully or partially) match a dictionary's definition.

Nevertheless, I think Scott has a point -- hell, everyone in this thread
has a point --: our current usage of INVALID really stretches the
commonly accepted usage of the word: very much, INVALID is anything that
is either not a bug, or not reproducible, or has no good (stack|
back)trace, or is not worth being fixed (for whatever reason), or
whatever. 

By marking 'Invalid' bugs that are either really invalid, or expired
(while in 'Incomplete'), or are older than a metric, or whatever else,
we end with the impossibility of finding what is what:
- how many bugs could not be reproduced (generically, for a given
package, etc)? 
- how many bugs were actually support questions (which we close --
Invalid! --, and open a question on https://answers.launchpad.net)? 
- What bugs were *really* invalid (by a dictionary's definition, say,
similar to NOTABUG)?
- etc.

We already grew the stati some time ago, by adding the 'WONT FIX' status
(which was, before, mixed in the INVALID). This was considered a Good
Deed. Perhaps it is time to give some more thought to this. And, yes,
this discussion seems to pop up about twice per year, with not much of a
result. Unfortunately.

We could get it by a careful re-edit of the stati (by adding some FEW
more, and changing the meaning of some FEW existing), *and* by a
judicious usage of tags.

For example: add in the status CLOSED, and tags nodata, noresponse,
onetime, etc; for INCOMPLETE, tags NoDoc, NoBackTrace, NoTestCase, etc,
etc, etc. Easy to do, although historical data will be a bit of a
problem.

We could get it by a (radically) different stati structure.

For example: create a hierarchical stati structure: 

OPEN
   Initial
   NeedsDoc
   Confirmed
   Triaged
   FixCommitted
CLOSED
   Invalid
   NotABug
   Support
   OneTime
   FixReleased
   WontFix

etc, etc. Not so easy to do, and historical data will be a nice problem
to tackle.

> These are real bugs that we choose to hide.

Which ones? All with a backtrace?  *Only* those with a backtrace? Or
perhaps those *without* a backtrace? How do you know they are all real
bugs? Who can verify it? What about the others?

But I agree that we are losing -- and, Scott is absolutely correct,
hiding -- important data, at a bare mimimum for time series analysis.

-- 
..hggdh..

p.s. Thanks, NullAck, for bringing this up (again).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20080821/1799fb5e/attachment.pgp>


More information about the Ubuntu-devel-discuss mailing list