[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #25383 [Metrics/Website]: Deprecate stats.html and stats/*.csv files



#25383: Deprecate stats.html and stats/*.csv files
-----------------------------+------------------------------
 Reporter:  karsten          |          Owner:  metrics-team
     Type:  enhancement      |         Status:  merge_ready
 Priority:  High             |      Milestone:
Component:  Metrics/Website  |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:                   |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:  irl              |        Sponsor:
-----------------------------+------------------------------
Changes (by irl):

 * status:  needs_review => merge_ready


Comment:

 Replying to [comment:29 karsten]:
 >  - Does it make sense to specify our per-graph CSV files there, rather
 than in the CSV file header?

 I think yes. The CSV files are machine-readable first, human-readable is
 not the priority for these files.

 >  - Is the format with two subsections Parameters and Columns okay? Is
 something missing?

 I think this is OK. Perhaps we need an example GET request to start this
 document off. We're really documenting an HTTP API, not just the
 individual files. Perhaps we need to say that either we do, or we don't,
 guarantee the ordering of the columns. If we add/remove columns later
 would we change the ordering? Especially with removal, would we pad with
 nulls or something like that? (Anything by transport is particularly
 affected by this).

 >  - Are specifications roughly correct/plausible?

 Nothing is jumping out at me as obviously wrong. I haven't considered
 every one thoroughly yet though.

 >  - Do the suggestions make sense? The rule of thumb for deciding which
 columns we need was: "it should require a code change to change columns,
 and neither the user should be able to control which columns exist by
 their choice of parameters, nor should the available data have any
 influence on that."

 The suggestions do make sense, and would solve the immediate column
 ordering issue (although we should still make a statement as to what we
 would expect to happen in the future). I commented on #26950 separately.

 > Regarding timing, how about we deploy this page still in July, make
 suggested changes by August 15, take out pre-aggregated stats files by
 September 15, and handle any questions coming out of that in the two weeks
 before the Mexico City meeting?

 Sounds good to me!

 merge_ready for this page.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25383#comment:31>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs