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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
