Rob asked on the launchpad-dev list whether people would mind seeing slightly inaccurate bug counts on some pages in Launchpad, if it meant the page would load faster.

So, if a project had 503 bugs its bug overview page might report that it has 500 bugs. However, for small numbers Launchpad would continue to report an accurate number, as the difference between three bugs and, say, no bugs is immense.

What do you think? Is a slightly inaccurate bug count a price worth paying for a faster page load? The survey closes 17.00 UTC Monday.

This entry was posted by Matthew Revell on Thursday, April 14th, 2011 at 1:29 pm and is filed under Bug Tracking.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.

8 Responses to “Survey: faster pages or accurate bug counts”

I’d rather have a faster page, I wouldn’t mind seeing “About 500 bugs” instead of “502 bugs”, because I wouldn’t do much with that specific info. If I wanted to know the exact bug count for some reason, I’d use something else anyway (API?).

I don’t think there’s anything wrong with returning approximate results, as long as they are not passed off as being accurate (scientists and engineers nearly always quote a tolerance or certainty in addition to the value itself).

Sometimes the answers might even be wildly out: this is what Google does, for instance it might say “About 174,000results”, and if you click down to page 50 you’ll actually find that it’s 259,813 as that level of detail is calculated.

We have 750K bugs, 900K bug tasks, and 10% are private (e.g. security fixes, private projects and so forth).

When you visit https://bugs.launchpad.net/ubuntu the query to get bug stats – like how many are new, untriaged, critical etc – ends up doing a table scan on the bug table (bugs have no context, only *tasks* know that they are for Ubuntu, or for a given package). That table scan and data summing take ~4 seconds in every plan we’ve tried.

If we build an aggregate model of the data – precalculating this – we can get completely accurate figures for public bugs, but because there are multiple ways an individual might see private bugs (e.g. they might be in the ubuntu security team *and* be the person that filed the bug in the first place) the aggregates can overcount *private bugs only*. We could mix aggregates for public bugs and direct queries for private bugs, but it would be slower than just using aggregates – as well as being a bit more complex. Most folk deal with few private bugs, and those that do tend to be more experienced users – my intuition is that we can do the simplest aggregate for now, and enlarge it to be more precise in private bug situations in the future.

@Paul I agree that we need to explain about the figures if they are going to be confusing people.