[tor-bugs] #21236 [Metrics/Metrics website]: Put a visualization of Tor Browser downloads and updates on the Metrics website

[Tor Bug Tracker & Wiki]

#21236: Put a visualization of Tor Browser downloads and updates on the Metrics
website
-------------------------------------+------------------------------
 Reporter:  karsten                  |          Owner:  karsten
     Type:  enhancement              |         Status:  needs_review
 Priority:  High                     |      Milestone:
Component:  Metrics/Metrics website  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:                           |  Actual Points:
Parent ID:                           |         Points:
 Reviewer:                           |        Sponsor:
-------------------------------------+------------------------------

Comment (by karsten):

 @gk: Thanks for looking!  I can't say much about those possibly confusing
 results.  But I'm pretty sure that these particular questions (downloads
 not showing in update pings, lots of update requests weeks after the last
 release) will only be the first of a series of questions that we'll have
 to look into.  I'd say let's deploy what we have now and discuss those
 questions when we have more data.  They'll either turn into bugfixes or
 frequently asked questions. :)

 @iwakeh: Thanks for all your input above!  I incorporated some of your
 suggestions, discarded others (see below), and made a few more changes
 while running tests and reviewing my own code once more.  Here's a summary
 of the changes:

  - After some back and forth I decided to postpone the `Database` class
 change.  It needs more work before being actually useful, and I don't want
 to share code between modules that's not ready yet.  Let's revisit this
 topic when we have enough time to fully encapsulate database functionality
 so that when we can easily mock it.

  - I also took out the part where we're parsing command-line arguments and
 put in `jdbc:postgresql:webstats` as database connection string.  I think
 that we can expect operators to make sure that the local user who runs the
 `java` process has permission to connect to that database without telling
 us the password.  And we can expect contributors to be able to edit the
 code and skip log files when developing.

  - I also tweaked the description a bit to avoid immediate concerns about
 privacy.  Not that this would eliminate all concerns, but hey.

  - Optimizing SQL queries might indeed be useful, though it's not an issue
 yet.  It probably helps that we have a separate `resources` table with
 unique resource strings.  We should keep this in mind though if module
 performance deteriorates over time.  (Such a thing has happened to other
 modules in the past, see https://lists.torproject.org/pipermail/tor-
 dev/2016-January/010139.html.)

  - I think I got the locale detection issues under control by tweaking
 regular expressions.

 There, I think that addresses all suggestions and open issues.  Please
 take a look at the [https://gitweb.torproject.org/karsten/metrics-
 web.git/commit/?h=task-21236-2&id=2d67509ae628a5d3102642bfcd13a6ec00b94e12
 fixup commit in my task-21236-2 branch], and please let me know whether
 that needs more work.  After that, I'd want to squash, rebase, merge,
 deploy, and announce.  Thanks!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21236#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online