launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Fri, Apr 15, 2011 at 11:11 PM, Jonathan Lange <jml@xxxxxxxxxxxxx> 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