14:00:32 #startmeeting metrics team 14:00:32 Meeting started Thu Oct 13 14:00:32 2016 UTC. The chair is karsten. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:47 agenda pad: https://pad.riseup.net/p/3M7VyrTVgjlF 14:03:03 alright, I don't have more topics to add to the pad. should we start? 14:03:07 yes. 14:03:12 * tiny new paragraph in team-page: https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam#CensorshipWatch (iwakeh) 14:03:16 looks good! 14:03:20 ok 14:03:29 that's what I wanted to hear :-) 14:03:40 I really hope we can include such data in the graphs at some point. 14:03:49 yeah 14:03:52 see the thoughts in the UI doc. 14:03:59 oh, speaking of, should we publish that? 14:04:02 as first draft? 14:04:09 sure. 14:04:34 tor-dev@? 14:04:47 hmm? 14:04:54 thinking about which list. 14:05:04 It's our target group, isn't it? 14:05:17 yes. should be good. 14:05:24 is there an analysis group ml? 14:05:50 no, that would be tor-dev@ I think. 14:05:57 fine. 14:06:13 ok. 14:06:14 * Globe redirect (karsten) 14:06:36 I didn't hear back from the admins, so I'd say we should just go ahead and change the redirect there. 14:06:49 and have it deployed for another two weeks before globe.tp.o goes offline. 14:06:57 would you want to write that patch? 14:07:06 yes, after sync. 14:07:21 was on last weeks list 14:07:31 of action items. 14:07:35 yep, here's what we wrote down: 14:07:38 - iwakeh: if sysadmins agree, make globe redirect manual and add expiration date 14:07:42 let's pretend they agree. ;) 14:07:58 okay, I'll move that to this week's action items list?... or you already did. great! 14:08:19 moving on: 14:08:20 * Ask another Tor person to help write CollecTor manual (karsten) 14:08:35 why? 14:08:37 I just thought that we might find another tor person to help with this. 14:08:44 ah, ok. 14:08:48 a native speaker who is less biased by knowing the code. 14:08:53 hehe 14:09:07 or have such a person test? 14:09:29 so, I have two folks in mind here. 14:09:32 they would have to know technical cmd-line stuff. 14:09:39 whom? 14:10:16 python devs with some java experience, I think. 14:10:25 sounds fine. 14:10:26 and 14:10:38 there is already the table draft. 14:10:47 ah yes, I was thinking to give that to them. 14:11:01 or, ask one of them to write a manual and the other to test it. 14:11:10 neat :-) 14:11:17 after 1.1.0 14:11:23 sounds good! 14:11:58 alright! 14:12:01 * CollecTor sync (iwakeh) 14:12:02 should we device a template? or, will they do that? 14:12:09 well, fine question! 14:12:24 the column headers in the 14:12:36 table would be good section headers. 14:12:51 I was looking at the privacy and security settings (onion button > privacy and security settings). 14:13:03 yes. I think we can suggest those, but let them decide to pick something different. 14:13:09 sure. 14:13:17 the text in the security slider tells me to "mouseover for more details," but nothing happens when I mouse over the text. 14:13:55 Sync? 14:13:56 hi linda. mind asking in #tor-project or #tor, or after the meeting in 45 minutes? :) 14:14:02 sync! 14:14:15 I'm working my way through comment 25. 14:14:33 Did you read about the path-blindness? 14:14:38 yes. 14:14:44 sure, I'll give more details. 14:14:50 very quickly, 14:14:57 related to tests. 14:15:05 I think there were some changes where you're using downloaded time in recent/, 14:15:10 so, only what should be there. 14:15:19 oh crap, sorry. 14:15:21 :/ 14:15:22 and in some cases there were singular/plural changes. 14:15:27 linda: no worries. thanks! :) 14:15:28 ah, we decided ealier 14:15:40 about the exit-lists .. 14:15:52 yes, so I wasn't sure if these changes were supposed to be there. 14:15:59 and the download time for merrged files in recent. 14:16:00 like, did we want to switch to new paths in this commit? 14:16:30 well, we can stay with old. 14:16:43 the download time is useful though. 14:16:46 might be easier. 14:16:54 oh, I think the changes make sense. 14:17:06 it's just a question of when to make them. 14:17:10 so, what to put in 1.1.0? 14:17:24 like, we should also make these changes to the other methods that write descriptors to disk. 14:17:25 is it a problem for main collector? 14:17:41 nope. we can change. but maybe in a separate commit? 14:17:51 then, just leave the exit-list singular. 14:17:59 and 14:18:06 I think microdesc vs. microdescs was another. 14:18:11 well, I'll go through them all. 14:18:13 do another commit on top with that change? 14:18:20 fine! 14:18:28 wait, what's the commit plan? 14:18:42 on top of the second branch after 14:18:44 change this commit to reflect what's in the other code, and then make another commit for the changes? 14:18:51 I worked through the comments. 14:19:35 the singular/plural changes, yes. 14:19:49 the download time for merges from synced 14:20:04 data I would prefer to put in immediately. 14:20:05 oh, I have another question about that. 14:20:14 sure 14:20:42 right now, the three existing data sources in the relaydescs module are run first, and then the sync happens. 14:20:53 in particular, the reference checker comes after the first three sources. 14:21:02 yes. 14:21:10 can we change that so that the sync happens as fourth data source, and then the reference checker? 14:21:21 Well, 14:21:48 the current three sources are not modularized yet. 14:21:51 I can 14:21:58 take a look and if 14:22:15 the change is minor it could be done. I basically 14:22:22 didn't want to touch the 14:22:32 current modules before sync is in place. 14:22:45 ok. 14:22:53 after the first sync 14:23:02 the difference is not to big anymore. 14:23:03 I'd say it's fine to put this on the list for now. 14:23:10 ticket? 14:23:12 and finish the sync. 14:23:13 yes. 14:23:23 yes. 14:23:32 oh, another thought (sorry for jumping around): 14:23:38 no problem. 14:23:58 can we add another property for data sinks, that is, recent/ and/or out/? 14:24:12 so that we can enable/disable those. 14:24:21 oh why? 14:24:23 longer term, but that would be useful for bridgedescs. 14:24:32 of course. 14:24:49 ah, now that I write it, we depend on out/ for deciding what to write to recent/. 14:25:07 yes but recent could be left out ;-) 14:25:12 hrrrrmmmm, let me put that on my list of things to think about first. 14:25:18 yes, recent could be disabled. 14:25:33 just make the tickets. 14:25:44 ok! 14:26:51 okay, what else should we talk about with respect to sync? 14:27:12 I think all is said what fits into irc. 14:27:26 ah 14:27:34 what about the stats db? 14:27:48 what would go in there? 14:27:55 yes. 14:28:25 I can't type to the pad anymore. 14:28:29 :-( 14:28:33 and is the goal to replace the reference checker? 14:28:42 and/or the other stats for missing descriptors? 14:28:52 (bad pad.) 14:28:56 well, it would make microdesc very easy and elegant. 14:29:01 I think. 14:29:06 oh, I was wondering about that. 14:29:14 we'd still have to make tarballs. 14:29:21 from out 14:29:39 and the correct date will be written in the out path. 14:29:40 yes, and we need to put microdescs in the right out/ dir. 14:29:53 how do we find out? 14:29:55 wich can be queried from the db. 14:29:57 ah! 14:30:11 but right now we have our own internal data structure for that. 14:30:22 which is not pretty, but which works. 14:30:26 but not in sync. 14:30:37 right, but sync could use that. 14:30:46 reparse everithing? 14:31:03 no, we're keeping a file where we store which descriptors we have and which we're missing. 14:31:16 well, parse that file? 14:31:34 this will be part of 1.2.0 so 14:31:52 micro,2016-10-12 15:00:00,000149e6ef7102aaca9690d6e8dd2932124b94ab,QmnPC/AIp0xqHEhe5Zii1lOwq5zbJeXzBfW92uGoeBg,2016-10-09 00:05:00 14:31:55 lines like that. 14:32:00 we can compare and decide. 14:32:09 209538 lines in the file, 27M large. 14:32:14 yes, I've seen these lines. 14:32:44 so, I can see us use a database for that, but it seems like a bigger change. 14:32:56 maybe out of scope for MOSS. 14:33:02 it's just an hsqldb. 14:33:08 part of sync. 14:33:21 but, first I can 14:33:30 look and 14:33:45 structure the upcoming tasks 14:33:58 so we get an idea how long things will take. 14:34:02 ideally, we'd use the same code for both downloading and syncing. 14:34:03 and then decide. 14:34:11 same code for finding out where to store a microdesc. 14:34:22 same code and same stats/ file or database. 14:34:38 agreed. 14:34:39 if you could reuse the code that's already there, that might be really quick. 14:34:53 and then we could replace that by a database thingy in the future. 14:35:03 I didn't rule that out. Just have the oom in mind. 14:35:04 in theory, all stats/ can go into a database. 14:35:15 I want to hunt down and kill that oom. 14:35:16 yes, that's the goal. 14:35:31 We get it. 14:35:34 :) 14:36:07 other sync topics? 14:36:35 what should I prioritize tomorrow, re sync? 14:36:46 the paths! 14:36:52 ok. 14:36:58 after that? 14:37:01 great! 14:37:13 the reviews of upcoming commits. 14:37:27 but I need the paths for that. 14:37:31 maybe 14:37:38 look at the protocol again 14:37:43 ok. 14:37:53 I relied on that. 14:38:00 for bridges at least. 14:38:12 as I only have a pure download mirror at hand. 14:38:18 right. 14:39:03 okay, looks like we have a few action items there. 14:39:08 yes :-) 14:39:22 but I think we're making some really good progress! :) 14:39:31 yep. 14:39:46 alright, back to work? 14:39:56 yes, back to work :-) 14:40:06 ! thanks, talk to you next week. bye! 14:40:06 bye, bye. 14:40:11 #endmeeting