On Wed, Apr 13, 2011 at 10:12 PM, Martin Pool <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
