Backtracing, Invalidated Bugs and Quality
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
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
- 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)?
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
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
We could get it by a (radically) different stati structure.
For example: create a hierarchical stati structure:
etc, etc. Not so easy to do, and historical data will be a nice problem
> 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.
p.s. Thanks, NullAck, for bringing this up (again).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part
More information about the Ubuntu-devel-discuss