Deployed.

(That cron is currently stopped to stop harassing the scheduler for nothing)

Awesome.

Rebase and plug to master

Aside one typo, lgtm.

lgtm

Update to the latest unbugged version

Update requirements

Rebase and plug to master

Rebase and plug to master

For the sake of my comment [1]

• loaders: Add missing class loader docstrings
• test_cli: Test the cli list's standard use

Move import statement at the top of the file

Rebase on latest origin/master

Other load-git migration tryouts (to keep a reference on):

tests should pass ok however no test exists for the interaction with the

scheduler, so...

The good news is that it's not the big part of the task.
So, yes, i'll improve on the current implementation that after i'm done deploying and migrating all the things ;)
The big part is the implied refactoring pulled by this.
Which i'm almost done (that's the deploy and migrate part i'm doing).

Use mix of CTE (with index) and random() to make query faster

yeah, that simplifies things!

In D2404#57201, @ardumont wrote:

materialized views.

We could implement a materialized view on a sliding window of the last 3 months visits.
And take a sample out of it.
pros:

• simpler? (i'm not that convinced ;)

cons:

• "more" maintenance (when and how to refresh it ~> periodic cron every night?)
• less parametric (current code is not, but we could adapt the current code to parametrize the current 3 months interval)

materialized views.

Did we really do any svn loads in the last three months? Maybe there's really nothing to show. In that case, the query _will_ do a sequential scan of the whole table.