Dear rocket scientists. I landed a branch that failed to fix bug #613610 [+needspackaging bug counts are wrong] https://bugs.edge.launchpad.net/launchpad-registry/+bug/613610
Pages are show the total number of bugs for a DSP, but when you follow the link, you see none. There are no open bugs. These numbers are a part of the heuristic rules for prioritising packages that need upstream links--the top 20 are insensible. I landed a small change to DSP.recalculateBugHeatCache() to ensure only open bugs were counted. This also changed the rules to for max_bug_heat to exclude closed bugs. The test look right. I now believe this was pointless, or maybe there is some disconnect in bug heat calculations. The numbers are not fixed on staging or edge on the DSPs I test. Reading the code again, DSP.recalculateBugHeatCache() is only called by bug.setHeat(), and that is really only called when a bug is marked as a dup, or bugtask is added/retargeted. I see Bug.updateHeat() called in many events that I expect to see a bugtarget's recalculateBugHeatCache() called. I looked at updateHeat() and saw we call a the PG calculate_bug_heat function. That is not updating the bugtargets. Looking at the HasBugHeatMixin.recalculateBugHeatCache() I see it is counting open bugs, which looks wrong--surely a project with no open bugs should be 0 bug heat. So how did DSP get such bad numbers if the methods that generate the numbers for bugtargets are rarely called. Are any of the bugtarget numbers really sensible? -- __Curtis C. Hovey_________ http://launchpad.net/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
