launchpad-dev team mailing list archive

[Graham Binns <graham@xxxxxxxxxxxxx>]

Hi folks,

We're working on getting bug heat calculations working before the Bugs
team sprint next week. We were originally going to do this on a daily
basis, with the script iterating over all bugs as part of garbo-daily,
but that takes too long (based on a test on staging it would take ~30
hours to update all the bugs we currently have, and that will obviously
increase as time goes by).

So, I've come up with a few ideas about how we could do it, and I'd like
to elicit your opinions on which might be the best one.

 Idea 1:
 - Add a heat_last_updated field to the Bug table.
 - When the bug is touched (in a way that generates heat, see [1]),
   reset heat_last_updated to None.
 - As part of garbo-hourly, have a script that will check for all Bugs
   where heat_last_updated is None and update their heat scores
   accordingly.

 Idea 2:
 - Use the Jobs system for heat calculations.
 - When a bug is touched, queue a job to calculate its heat.

 Idea 3:
 - Use an Event to update bug heat whenever a bug is touched.

Note, in each of these cases we would still have, as part of
garbo-daily, a script that will check all bugs whose heat hasn't been
updated for an arbitrary period of time and update their heat
accordingly.

My own thinking is: 

 - Idea 1 is the least complex to implement (at least with my current
   knowledge set).
 - Idea 3 is a bad idea (because we have to hit the
   subscribers-from-duplicates when calculating bug heat and that causes
   timeouts)
 - Idea 2 is the most scalable.

So, have at it Launchpadders! I await your wisdom with bated breath.

 [1] https://dev.launchpad.net/Bugs/BugHeat#Algorithm

-- 
Graham Binns | PGP Key: EC66FA7D

Attachment: signature.asc
Description: Digital signature