launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Wed, Apr 13, 2011 at 10:12 PM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
> As a user, I think being approximate is generally speaking fine, with
> a couple of caveats.
>
> There are some counts that people want to drive to 0, such as critical
> bugs, new bugs, inprogress bugs, maybe high bugs, maybe bugs assigned
> to me.  If the count for them doesn't go to 0, or conversely if it
> goes to 0 when some items still exist, it will be
> annoying/confusing/frustrating.

This is a good point; my prototype schema will never show 0 as nonzero
- it will only show nonzero (calculated using source data) as possibly
higher-nonzero (calculated using the summary table).

>  I've hit this before when these
> things were memcached (iirc).  Some projects/teams may use tags for
> similar important workflow things.  I wouldn't notice 500 vs 700 but I
> would notice 2 vs 3 critical bugs.

Indeed. OTOH I think with 2 critical *private* bugs you'd been quite
unlikely to be subscribed twice. IMBW.

> Secondly if it does happen that people get an accurate count through
> the api or through paging through all the results, it may be
> disconcerting if it doesn't match; but perhaps that can be handled by
> just indicating that the numbers are approximate, or again being
> accurate at low numbers.

I would like the API to use these summaries as well where we can. We
have a bunch of work to do to break the assumption that the results
set is at all like a list object first; my current batchnav 1.2.4 work
goes someway towards that, but there is more to do.
I agree that it *could* be disconcerting, but as I say: these summary
numbers were broken for *7 years* and we had 1 - yes '1' - bug report
about their accuracy.

-Rob