-importance sort order uses bug task id for stability
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned |
Bug Description
I currently see the last 5 bugs as:
High
Triaged
#919369 cannot retarget bugtask and update status at the same time
Launchpad itself Tags: 404 bugs javascript 0 out of 4 heat flames
High
Triaged
#757007 total_size element returned in all batch retrievals
lazr.restfulclient Tags: None 0 out of 4 heat flames
High
Triaged
#918307 Declares that it requires the test dependencies, but doesn't depend on them, breaking other python code
lazr.restfulclient Tags: None 0 out of 4 heat flames
High
In Progress
#920566 private_bugs is not exposed over the API
Launchpad itself Tags: bugs disclosure privacy projects 0 out of 4 heat flames
Note that these are all high and the sort is by -importance. Historically we used to use the bug id for stability, (so would have had -importance, +bug.id, +task.id) but now are not including the bug id. This is a little surprising for users (heck, it surprised me and I suspect I made that change for performance).
We might want to examine the ramifications of putting it back in (or denormalising onto whatever search schema we have (e.g. tasks).
tags: | added: bug-search |
This is cheap to do now. We just need to add the new indices to BugTaskFlat, change the tiebreaker in lp.bugs. model.bugtaskse arch, and drop the old indices.