Search Index should respect package Updates too

[jeffhandley]

Presently, the search index only respects package Installs for boosting relevance. We should respect Updates too (but only direct updates).

In the scenario of a package that has been around a long time and updates regularly, the package shouldn't get penalized for having been around a long time and therefore not getting a large, fresh install base anymore. Instead, if that package updates regularly, it should get boosted for those updates too, so that the users that don't yet have the package can still discover it.

However, we should boost Updates significantly less than Installs. Perhaps half as much? So that updates of a popular package don't completely overcome installs of a newly popular package.

[jeffhandley]

@anurse - I chatted with @johnataylor about this. He suggested having the Updates number in the index as a separate field. Please chat with him about how it can be integrated.

Thanks!

[analogrelay]

It should just be a matter of adjusting the queries that generate the ranking report from the warehouse to include Updates in the count. Trivial.

Do we want to consider Updates as equivalent to Installs or scale them in any way?

[analogrelay]

Ok, re-reading this I've got some clarity. However, we don't really store Installs in the Index at all, just total download count. The Ranking by Install is done using the report generated by the Warehouse. So I'm not sure adding updates to the index is helpful. Instead, my suggestion would be to factor in Updates in the rankings report at a factor of 0.5. Basically, instead of getting the 200 most installed packages, we'll take all packages, sum their installs (I) , sum their updates (U) and calculate R = I + (0.5*U), then order by Descending R and take the top 200.

[analogrelay]

See the PR for an example.