14:00:06 #startmeeting metrics team 14:00:06 Meeting started Thu Jul 14 14:00:06 2016 UTC. The chair is karsten. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:06 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:13 hi, who's here for the meeting? 14:00:25 me :-) 14:00:26 me 14:00:35 hi iwakeh and anathema_db! 14:00:46 please add topics to the pad. 14:00:53 https://pad.riseup.net/p/zUNzEIFRq5S4 14:00:57 hi karsten 14:02:31 I confess: I didn't read last meeting's minute 14:02:43 no problem 14:02:44 no worries. :) 14:03:06 but I'd like to know more about the python style guide and if there are any news on the Berlin meeting 14:03:19 well, 14:03:28 I'll add it to the pad. 14:03:34 k thanks 14:04:33 I've just added one small thing 14:04:38 it's more of a question 14:04:48 sure. 14:04:59 okay, 5 minutes into the meeting, let's start with agenda item 1. 14:05:03 * MOSS award start date (karsten) 14:05:12 we're free to pick a date of our choice, and we picked july 1. 14:05:20 ok. 14:05:29 so, the award will run from july 1, 2016 to june 30, 2017. 14:05:36 which is good, I think. 14:05:45 yes. 14:05:53 nothing more about that. paperwork still in the making. 14:06:05 cool 14:06:16 moving on to... 14:06:17 * Berlin meetup (karsten) 14:06:18 there will be any kind of new team? 14:06:24 hmm? 14:06:36 new organisation, new people working on the MOSS award items? 14:06:46 ah, right. 14:06:53 or we'll spread the workload among us ? 14:07:38 that's still a bit unclear until the paperwork is signed, except for iwakeh's work which is already part of the award. 14:07:48 ok, great 14:07:58 but we'll have to think about what we do with the remaining funding. 14:08:24 or rather, make decisions. we already thought a bit about this a few weeks ago. 14:08:26 yeah I guess we need to address how to use them 14:09:11 so, related to this, I put up the deliverables a week or so ago. 14:09:14 let me find them. 14:09:26 m 14:09:27 https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorX 14:09:28 *k 14:10:01 ok 14:10:06 read it, thanks 14:10:35 I hope we'll add more content to that wiki page soon. iwakeh, let's think about that this week, ok? 14:10:50 right, I started tht a little. 14:11:18 should we link back to the sponsorX page? 14:11:29 from other pages? sure. 14:11:41 ok, fine. 14:11:45 or from that page to others? sure, that, too. 14:12:01 alright. Berlin! 14:12:06 https://trac.torproject.org/projects/tor/wiki/org/meetings/2016BerlinMeetup 14:12:11 we have a weekend. 14:12:16 well ... 14:12:23 oh so we already have a date? 14:12:23 good 14:12:52 we're not going to spend the full three days on metrics stuff. 14:12:54 ;) 14:12:58 eheeh 14:13:03 maybe we should find more detailed time frames? 14:13:19 reserve the space 14:13:35 for metrics only topics? or some space? 14:13:56 we could start by picking 1 of the 3 days for metrics stuff. 14:14:09 but not on the current meeting. 14:14:16 maybe doodle again? 14:14:28 yes, sure. 14:14:39 I'll start a doodle for that. 14:14:45 sorted 14:14:46 great! 14:15:12 so, if you're planning to attend at least one day, would you mind putting your name on the wiki page? 14:15:18 can someone put the address of the Onion Space? 14:15:21 right now it looks like we'll be three people. 14:15:27 unclear! 14:15:33 I don't know how public it's supposed to be. 14:15:40 ah ok, got it 14:15:43 it's in Berlin Wedding. 14:16:06 four people ;-) 14:16:09 but I'll have to ask them if they want the address to be public. otherwise we'll share by email. 14:16:10 well, I'm in the middle of changing company so I've to double check if I can take Friday off 14:16:14 yay, it's growing! 14:16:17 will update later in the month 14:16:34 okay, I'll make that doodle a yes/no/maybe. 14:16:51 so, anything else about berlin? 14:17:05 no I'm ok 14:17:11 * documentation for projects (iwakeh) 14:17:12 Development documentation: 14:17:20 proposed new section on team page with links to project pages: 14:17:30 https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam#Projects 14:17:38 just place holders 14:17:54 to get an idea; more in CollecTor 14:18:24 hmm, would it be too much to include what specifically the project will be about? 14:18:37 Well, that's the ToDo 14:18:49 oh okay. 14:19:28 Is the list ok? 14:19:46 I mean: "This list is not exhaustive, but rather lists some long-term ..." 14:19:50 should we add Atlas? 14:19:58 Sure. 14:20:01 probably, yes. 14:20:28 but, are we talking about the same definition of project here? 14:20:38 mm 14:20:39 defined start and end date, can fail, etc. 14:20:42 That's what I try to find out. 14:20:44 rather than code base. 14:20:53 Ah, 14:21:08 you intended a project plan ? Gannt chart? 14:21:20 well, I can imagine two things: 14:21:29 1. a list of actively maintained code bases, 14:21:42 agreed. 14:21:44 2. a list of active projects to improve some code base in some way. 14:22:14 I think, for 2. we'd have to do too many wiki page updates. 14:22:15 where a project could even affect two code bases (onionoo change and corresponding atlas extension), 14:22:26 and there could be 0 or more than 1 projects for the same code base. 14:22:40 okay, so 1. 14:22:48 I think that could be confusing so maybe it's better to stay with 1. 14:23:12 thanks, that's what I indended to find out 14:23:18 before writing more. 14:23:28 is there a better word for project then? 14:23:29 Therefor the TODOs. 14:23:34 codebase 14:23:46 is fine, but technical. 14:23:56 I think project is fine 14:23:57 in the past I used product or codebase, I think. 14:24:11 product sounds like corporate 14:24:14 :) 14:24:16 product or areas of work 14:24:17 well, many people say project, but that's confusing. 14:24:27 with other projects that start, end, fail, err. 14:24:39 code project? 14:25:03 Systems 14:25:04 agree with the "code" part. ;) 14:25:17 code project systems. 14:25:18 lol 14:25:19 hmm, https://www.torproject.org/getinvolved/volunteer.html.en#Projects says projects, too. 14:25:35 okay, just a thought, no need to find a winner now. 14:25:47 which makes sense 14:25:48 darn, didn't we want to finish in 30.. 14:25:55 I'll leave it as project for now? 14:25:58 ok. 14:26:20 the versioning could wait 14:26:28 okay, moving it down. 14:26:32 * python style guide next steps (iwakeh) 14:26:48 (guess we can go until :45 like last time) 14:27:02 well, I intend to propose PEP8 to metrics-ml 14:27:12 I agree with PEP8 14:27:25 if noone yells, that's it and later addition are wellcome, of course. 14:27:36 sorted. :) 14:27:41 ok. 14:28:03 it sounds like the right decision. 14:28:11 without having written much python, that is. 14:28:12 yes, it reads fine 14:28:21 the guide PEP8 14:28:23 and is 14:28:31 close to what we use in java. 14:28:38 cool. 14:28:41 as far as possiblee. 14:29:01 okay, moving forward? 14:29:06 k 14:29:08 yep. 14:29:10 * Onionoo addinational infos (anathema_db) 14:29:24 yeah so you may already know what I'm talking about 14:29:32 protocol? 14:29:48 * karsten hasn't read that thread in detail yet. 14:29:49 I'd like to know if there are any stats on the service/code 14:29:54 ah. 14:30:07 you mean specifications of the machine? 14:30:10 no more about system usage, benchmarks 14:30:21 users/hour? 14:30:30 like ram consumption, cpu workload under avg/max load 14:30:44 https://munin.torproject.org/torproject.org/omeiense.torproject.org/cpu.html 14:30:50 all data science python i have seen was pep8, great choice :-) 14:30:51 have you in mind apachebenchmark output? 14:30:56 user tor-guest, password anything 14:31:07 @qiv, thanks. 14:31:34 karsten: is that specific to Onionoo's server? 14:31:45 anathema_db: omeiense is onionoo only. 14:31:46 I'm more interested in how much resource Onionoo process takes 14:31:51 cool 14:31:58 and how about benchmarks? 14:32:16 like time to respond to a request, amount of data returned, etc etc ? 14:32:19 iwakeh: there is one exception though, tensorflow, they use google ... but anyways, i love pep8 14:32:37 anathema_db: there's the stuff that gets logged. 14:32:53 anathema_db: I might have shared that in the past, but let me find a recent output. 14:33:37 you shared some data that was extracted from the code itself 14:33:40 anathema_db: http://paste.debian.net/781283/ 14:33:41 with a specific class 14:33:54 yes, that's custom code. 14:34:04 logging, actually 14:34:13 yeah I''m more interested in benchmarks 14:34:25 that's all we have, I think. 14:34:26 that's one form of benchmark. 14:34:33 something like: 14:34:39 (waiting for link...) 14:35:17 I used Jmeter long ago for Onionoo, but not data anymore ... 14:35:36 https://paste.debian.net/781284/ 14:35:55 yeah I may get into jmeter as well, just need to study it 14:35:58 I'm more familiar with ab 14:36:06 but that's the kind of data I'm interested on 14:36:29 so that's just 1 request 14:36:34 I think Jmeter is quite good for that purpose. 14:36:43 it is yes 14:37:10 But that also measures network and other outside parameter. 14:37:21 so I'd like to know what is the consumption of RAM and CPU when under load 14:37:27 even more for multiple requests 14:37:55 yep, more a real case scenario (simulating a client) 14:37:56 the log statements I pasted were just from the java part that answers web requests. 14:38:13 there's also a varnish cache now that prevents many, many requests from ever reaching the java part. 14:38:19 and there's of course network overhead. 14:38:31 I'm open to adding more measurements. should we do that on trac? 14:38:36 ah ok good for varnish 14:38:38 yes. 14:38:45 can you explain also the architecture? 14:38:54 of onionoo? 14:39:01 which detail? 14:39:22 maybe, per mail? 14:39:24 architecture 14:39:25 ah, you mean, some overview that includes the word "varnish"? 14:39:30 yeah sure, mail is fine 14:39:48 sounds good. 14:39:58 like the java service, then nginx (example), varnish cache 14:39:59 etc etc 14:40:09 the db 14:40:17 and so on 14:40:18 yes! want to ask on the list, and iwakeh or I respond? 14:40:32 or both. 14:40:35 sounds good 14:40:43 great! 14:41:02 anything else about onionoo? 14:41:17 by the way, feel free to move the discussion back to the mailing list. 14:41:25 perfect, thanks 14:41:28 I'm good for now 14:41:31 we can move forward 14:41:35 ok. 14:41:38 * release process, i.e. use versions or tags or (iwakeh) 14:42:08 for bundling issues in a release versions would be neat. 14:42:11 tags are easiest, but we can work with other trac features. 14:42:23 tags also cause mails. and 14:42:36 you could just create a batch of new versions in on ticket? 14:42:59 I think we should sort early 14:43:00 so, hmm. 14:43:15 e.g. descriptor 2.0.0 and 1.4.0 and ... 14:43:22 I think tor uses versions to say which version contains a bug. 14:43:28 not which version should contain the fix. 14:43:37 ah, ok. 14:43:37 it uses milestones for that. 14:43:47 well, that's fine with me 14:43:54 and I can create versions and/or milestones as needed. 14:44:06 I should create a ticket and list them, then create them, then close the ticket. easy. 14:44:09 milestones has a nice overview 14:44:19 ok. fine. 14:44:33 do you have a list? 14:44:45 or just those two for descriptor? 14:44:46 in my head :-) 14:44:49 heh. 14:45:06 and for the others the very first 14:45:23 releases and also the next ones for 14:45:32 fixes and mini features. 14:45:51 we could make a list 14:46:01 in the new ticket before you create them. 14:46:04 hmm, on second thought, I don't think we need to document creation of new milestones and versions. just components. 14:46:12 but having a ticket wouldn't hurt. 14:46:14 even better 14:46:27 to create this list. 14:46:37 right. 14:46:48 want to create a ticket when you have a good first list? 14:46:55 ok ;-) 14:47:15 or, send me the list, and I create the ticket? 14:47:22 also fine. 14:47:32 I'll mail the list. 14:47:33 * karsten thinks of other people seeing the ticket and going ahead with creating things. 14:47:37 great! 14:47:40 oookaaaay 14:47:49 anything else for today? 14:47:54 I'm good 14:47:54 all done. 14:48:03 wonderful. thanks for a great meeting! 14:48:10 thanks to you guys 14:48:14 talk to you in a week. 14:48:17 thanks. bye bye. 14:48:18 #endmeeting