launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxxx>]

Hi,

> But as I refactor lp.bugs.model.bugtasksearch, I notice that there are
> some mildly crazy sort orders, most notably "specification" and "tag".
> Both of these take the alphabetically first linked spec or tag for each
> bug, and sort alphabetically based on that -- not exactly obvious,
> performant or useful.
>
> So I'd like to drop them. "specification" doesn't seem to be accessible
> from the UI at all, but "tag" has a sort lozenge. I seem to recall that
> the lozenges also exist as a bit of a legend for the table content, so
> perhaps dropping the tag lozenge is not ideal. What do people think?

I think you should drop them.

I can imagine people might have sorted by spec, or assignee, as a more
accessible and discoverable ui than filtering, when all they really
want is a filter.

> Relatedly, various other orders will continue to be slow on large sets
> of bugs. Some are never going to be fast without further denormalisation
> and big new indices that probably aren't worth it (eg. reporter,
> assignee, milestone_name, targetname), and others are sufficiently rare
> or unuseful that it's probably not worth optimising for them
> (number_of_duplicates, message_count, title, maybe users_affected_count,
> latest_patch_uploaded come to mind).

I have used number of duplicates, and affected user count, to look for
neglected high impact bugs.  I can imagine people doing similarly for
last patch date (maybe).

> Given the timeouts-are-critical policy, it seems less than ideal to
> leave these slow sorts to time out. We could perhaps limit their usage
> to smaller sets of bugs, but that is awkward and poses challenges of its
> own. Ideas?

I guess you have logs that show how often they are used and what
fraction of the time they time out.  If they are never used, perhaps
it doesn't matter either way.  I suspect they are used, and when
they're used it's not accidental, the person really does want that
sort.  In that case having it available, even if it sometimes fails,
is probably better than not having it at all, especially because these
queries tend to work if you retry them.

I would leave them in, and wait for people to vote up the bug
complaining that they time out.  I've seen many more bug timeouts from
text searches than anything else (but maybe that's now fixed?)

-- 
Martin