launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Fri, Apr 15, 2011 at 1:25 PM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> wrote:
> 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.

Sounds great. I'm happy for this to go ahead after stakeholder consultation.

jml