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).
signature.asc
Description: This is a digitally signed message part
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
