launchpad-dev team mailing list archive

[Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx>]

Hi, Curtis.

On Thu, Aug 19, 2010 at 6:07 PM, Curtis Hovey
<curtis.hovey@xxxxxxxxxxxxx> wrote:
> 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?
>

As I mentioned on IRC, I think this only needs a couple minor changes
to fix the remaining issues.

Your calls to recalculateBugHeatCache should happen inside updateHeat,
not setHeat.  The method names are confusing and we should add some
comments to explain (or perhaps even rename setHeat).  updateHeat is
the single method where any heat calculations should take place.
setHeat is only used in rare instances were you want to bypass
calculating heat and just set a number directly.  As far as I know,
this is only used to set heat to 0 for closed bugs or bugs with
duplicates.

Also, you will want to filter out duplicate bugs from your counts as
well as the closed bug statuses you already handled to prevent dupes
making the bug count higher than it really is.

Hope that helps solve the problem.

Cheers,
deryck




-- 
Deryck Hodge
https://launchpad.net/~deryck
http://www.devurandom.org/