On Wed, Apr 13, 2011 at 11:00 AM, Robert Collins <[email protected]> wrote: > https://bugs.launchpad.net/launchpad/+bug/758587 describes a challenge > we have; counting bugs is expensive. > ... > We have a choice: > - make the data utterly precise > - be a bit simpler and accept some inaccuracy ... > So, specifically to jml & Deryck, but also to the whole team and any > users following this discussion: is it ok to be slightly inflated but > fast? >
As others have said, for drive-to-zero lists, it's important to be both precise & accurate at low numbers. This goes for bugs in general and many sublists of bugs (Critical & Needs triaging being two obvious kinds), but also goes for merge proposals, untranslated strings and so forth. I think it's also important to allow API users to get precise numbers if they need them, with some discoverable, reasonable promise about the accuracy. The ideal would being able to get numbers that are fully precise and fully accurate. I think that default APIs can afford to be imprecise. Thanks for chasing this up. jml _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
