16:59:37 #startmeeting network team meeting, 21 Aug 16:59:37 Meeting started Mon Aug 21 16:59:37 2017 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:37 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:01 hi everybody! 17:00:08 hello 17:00:09 hi 17:00:10 hi 17:00:12 hello hello hello 17:01:15 catalyst: btw, if this meeting intersects with anybody's eclipse time, please take an eclipse break 17:02:00 * asn reads reports 17:02:15 I think I'm going to be doing a lot of code review this week too... 17:02:35 but also I have a bunch fo stuff in review-group-22 that's been waiting for a little review 17:02:39 *of 17:04:03 pastly: is the ticket/branch is in need_review right? 17:04:16 pastly: ticket number ? (so I can put it on my priority stack) 17:04:28 dgoulet: just a moment I'll get you the ticket num. 17:04:50 dgoulet: #12541 17:04:54 Is ahf around today, or still away? 17:05:03 pastly: thanks 17:05:14 nickm: pretty sure he is away for BornHack 17:05:18 ok 17:05:43 - 21/8 and 22/8 - Build Up (not online at all) 17:06:58 Does anybody remember who wanted #22407 ? I know people have been promoting it for a long time, but I forget who 17:07:09 but I figure maybe we could get them to test it :) 17:08:39 catalyst: where are with bootstrap progress reporting? If we wanted to get an initial _something_ to the TB team pretty quickly, what would the timeline be? 17:08:55 and would I help or hinder more by jumping in? 17:09:17 pastly: you saw my review on #12541, yeah? I can't remember if I told you; it was so long ago... 17:09:20 :) 17:09:58 Yup I saw them. Thanks a lot nickm :) 17:10:18 hi !! 17:10:22 Mostly that I didn't read the style guide well enough 17:10:22 nickm: right now a lot of the stuff that would be helpful to report out is buried quite deeply in enormous call stacks; it would help to refactor that somehow (but i'm not sure how yet) 17:11:00 catalyst: so, it's actually okay to send control events from deep inside enormous call stacks: control events are queued in control.c, and actually sent later, so it doesn't risk introducing circularity... 17:11:10 I'm not sure if that's what you were saying though 17:11:38 part of the problem is when you need to report something from deep in a call stack but don't have the context to know whether you're being called in the way that you're meaning to report 17:11:47 ah. 17:12:05 do you have a list of all the stuff we want to start reporting, and a list of where to report it and what's hard to report 17:12:08 ? 17:12:14 If so I could try to help figure out ways to report stuff 17:12:36 it might also be fine to just add reporting for the things that are easy now, and do the hard stuff afterwards 17:13:00 e.g., the roundabout way we handle BOOTSTRAP_STATUS_HANDSHAKE 17:13:55 there's other stuff that tries to figure out whether it's being called in a particular bootstrap phase to decide whether to report it out 17:14:48 ouch, that one _is_ gross. 17:15:12 almost tempted to drop in generic progress reporting to connection setup code and have the upper layers sort it out (they have easier access to the required context after all) 17:15:30 that actually sounds pretty smart. 17:15:47 like, just tell the control.c code about events, and have a state machine there that turns the events into progress status? 17:17:53 yeah that way controllers can have models of detailed progress of individual ORCONNs 17:18:23 hm 17:18:41 I think that the controllers (like tor launcher) really do want the bootstrap status... 17:18:58 ... but that converting or conn status into bootstrap status at a higher layer would be fine 17:20:51 another example is how we decide whether to report BOOTSTRAP_STATUS_CONN_DIR in circuit_handle_first_hop() 17:24:11 but, are you thinking of having a higher layer in Tor convert this stuff to bootstrap progress? Or exposing fine-grained events to the controller and making them determine the progress? 17:24:21 because that latter one will take more engineering on their part 17:24:35 IIUC, I think I would like that too: just 'events' that happen or not, and my controller figures out how much "percent progress" we've got 17:24:50 having a higher layer convert the detailed circuit progress into bootstrap progress. sophisticated controllers can get more detailed events 17:24:58 ack 17:24:59 (because I mess with the precent *anyway* to, e.g., account for 'upload the descriptors') 17:29:36 catalyst: that makes sense. So back to my earlier questions: do you think we're ready to declare a rough timeline there for isabela ? and would it help if I jump in too? 17:32:07 also, has everybody had a chance to look at dgoulet's scheduling email? 17:32:24 dgoulet: did you mean the one on the thread "lets build our schedule for teams meetings day in montreal" 17:32:29 yes 17:32:49 I replied with 3 sessions and put some timeslot in the schedule 17:33:06 dgoulet: I think maybe we could benefit from some "what would we like funding to do" discussion as well -- not sure where that fits in, but it could be brainstormable 17:33:43 nickm: yes, maybe we can roadmap for an hour and then transition to that 17:33:49 (with session (3)) 17:34:28 Is this where there is a dev meeting today at 11:00 UTC-7? 17:34:59 there's a dev meeting right now! 17:35:08 and another one in 25 minutes 17:35:20 dgoulet: sounds good; shall I say that on the thread or would you like to? 17:35:26 nickm: go for it I say 17:35:30 ack 17:38:18 any other topics for today, or shall we call the meeting finished and move on to code reviews? :) 17:38:27 * dgoulet is good 17:38:40 nickm: i think first phase is to either add PT and proxy progress reporting to control_event_or_conn_status() or make new abstractions for reporting them 17:39:20 that's not directly actionable by the Tor Launcher people yet: that would have to wait for some refactoring of the bootstrap reporting, which might get very hairy 17:41:45 so i'm trying to think of how can we get the Tor Launcher people some useful stuff ASAP without adding more tech debt to what we've got 17:42:32 maybe we can improve error reporting or add events they wanted for some other part of the process ? 17:44:06 or maybe we can write a quick spec of what the events _will_ look like, so that they can be ready for them 17:44:37 oh, having a translation layer between symbolic bootstrap phase names and progress numbers would probably help a lot; that way people won't be squinting at the new phases 1..4 that we add to handle intermediate PT and proxy phases 17:45:17 (the alternative would be having Tor Launcher do that translation on its own and that would be trickier) 17:45:55 but the translation would depend on whether proxies or PTs are configured 17:51:05 true 17:51:21 do you think we can get isabela the timeline she wants, or should we plan more first? 17:53:29 what is the tbb-team timeline like? maybe we can shuffle priorities to give them incremental usefulness in that window 17:55:33 I think it's september some time, but I'm not 100% sure 17:55:52 we're about at the end of our time though, so let's try to bang something into shape later today or tomorrow? 17:55:58 sure 17:56:00 anything else for the next 4 minutes? :) 17:56:55 #endmeeting