On Fri, Apr 15, 2011 at 11:11 PM, Jonathan Lange <[email protected]> wrote: > 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 agree its important; Is it tolerable to have fuzz *on private bugs only* in this area while we continue to drive our service times down? For clarity: - this only affects portlets, not the number of results predicted for a search - any count which is actually zero would show zero - any count which has private bugs in it may count [some of] those bugs more than once. - we would have no latency on updating the numbers Expressed as a delta against the current situation: - the various bug portlets would be about as accurate - which is more accurate than they were 3 months ago (when I fixed an extremely similar bug which had had 1 report filed). Based on both the polls Matt put together, and gut feeling, I think it would be a net win to make this fast, and come back when we're not fighting a sluggish system all over the place and iron out how to get accuracy and precision for private bugs. > 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. As the API uses .count() on storm searches, any work in this area wouldn't by-default affect the API. -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
