launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

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/

Attachment: signature.asc
Description: This is a digitally signed message part